On Mon, 14 Nov 2005, Tim Jenness wrote:
> I don't think $STARCONF_DEFAULT_PREFIX actually works. At least, it doesn't
> work the way I expect it to.
>
> I was expecting that
>
> STARCONF_DEFAULT_STARLINK
> controls where the currently installed Starlink system is
> located for building the application.
>
> STARCONF_DEFAULT_PREFIX
> controls where the newly built application is installed.
> ie this is the path burnt into the configure script.
>
> But it doesn't work like that since I still have to use --prefix on the
> configure line to override the install location. What am I missing.
Hi Tim,
is kind of what you expect, but looking at SSN/78, there's an explanation.
The values of STARCONF_DEFAULT_PREFIX and STARCONF_DEFAULT_STARLINK are
baked-in properties of "starconf", not the individual packages.
So bootstrapping a package doesn't take any notice of these values, they
are only effectively used during "bootstrap --buildsupport".
The only ways to set "prefix" for a package are by using "--prefix" during
configure, or to add it to a local acinclude.m4 file. See:
http://www.astro.gla.ac.uk/users/norman/star/ssn78/ssn78.htx/N-a2b2c1.html
!
Cheers,
Peter.
|