This is the mail archive of the cygwin-apps 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: g-b-s and bin dir


Warren Young wrote:

> the corresponding autoconf variable.  As g-b-s runs configure, ${bindir)
> ends up being /usr/bin, so when the g-b-s inst step runs, the binaries
> go to /usr/bin, not to $UNPACKED_TARBALL/.inst/usr/bin.

Most standard autoconf/automake-generated configure scripts support the
use of DESTDIR for the "make install" step.  This lets you use the
desired --prefix=/usr but divert the destination at the final install
step by doing "make install DESTDIR=/some/path", causing the tree to be
installed to /some/path rather than /usr.  But note that the package is
otherwise still configured to be installed in /usr, so for example if
there are any hard coded paths they will reference /usr and not
/some/path. 

I think this is what the GBS uses to redirect the install to the .inst
dir.  If the ctags configure script does not have this capability then
you will have to do one of:

1. Manually recreate the install tree by copying stuff out of /usr and
into .inst/ for inclusion in the binary package.

2. Patch configure.ac/.in to honor $DESTDIR for the install target and
regenerate.

3. Configure with --prefix=/some/temp/packaging/path/.inst and hope that
this prefix is not hard coded anywhere in any files.

#3 is risky but probably okay for very simple packages.  #1 is easy but
clumsy.  #2 requires that you maintain local patches to configure.ac,
and re-run autoconf to rebuild generated files.

This last point touches on another issue: Do you include patches to
generated files in the source package?  One school of thought says that
you do since it's simpler and the end user that builds the package
doesn't have to worry about having the correct version of
autoconf/automake/libtool installed.  However this can result in huge
(multiple-megabyte) patches since the generated files can often be quite
large, and it really obscures the actual patches (if any) from the noise
of the diffs in generated files.

The other school of thought is that you should only include patches to
the configure.ac (and other primary source files), and modify the build
script to first run autoreconf to regenerate everything before
configuring.  This makes for nice, small, easy to inspect patches, but
the user building the package from source must have the proper developer
tools installed and must know to either run autoreconf or use your build
script.

Brian


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