This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Generic build script instructions


> Well, yes, I agree that if you really anticipate having to maintain
> multiple packages from the outset, and want to keep more or less the same
> build procedure for each of them (helps if they are related), you should
> probably start already with something more sophisticated than the gbs.

I don't know.  The gbs seems to be pretty good at accomplishing
it's goals without introducing a whole lot of extra overhead;
the main problem would seem to be that there's really no way
to customize the script without altering it.

So, to answer that question, why not something like this:

  # --- BEGIN_DEFS ---
  if [ -f ${FULLPKG}.defs ]; then
    . ${FULLPKG}.defs
  fi
  # --- END_DEFS ---

So, if my source package name is foo.tar.Z, then I can put the
following in my defs file:

  # Maintainer defs file for package foo
  src_orig_pkg_name=foo.tar.Z
  opt_decomp=z

This would allow a package maintainer to put specializatons/
definitions within a defs file for each package, making for
easier maintentance (except in cases of siginificantly unusual
packages).

Next, modify the gbs so that the version of the gbs that
gets included as part of the source package is result of
merging the defs file and the canonical gbs.  In the above
example, when the maintainer built the source package,
everything in between the BEGIN_DEFS and the END_DEFS lines
would be replaced with the actual contents of the maintainer's
def file for the package, so that the packaged gbs would
actually look like the following:

  # --- BEGIN_DEFS ---
  src_orig_pkg_name=foo.tar.Z
  opt_decomp=z
  # --- END_DEFS ---

For this to really be effective, you'd have to have the ability
to override more than just the source package name and the
decompression flags :-/

You could probably get fancy, and do things like allow the defs
file to override individual functions (ie, unpack() checks to
see if defs_unpack() is defined; if it is, it calls defs_unpack(),
otherwise it calls std_unpack(), etc.)



-Samrobb


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]