Tim,
On 2005 Apr 12 , at 23.39, Tim Jenness wrote:
> So is this actually saying that dist tar balls retrieved by users
> will
> not build unless they install it in to the same place it was originally
> built for? (since --prefix is useless unless you have all the dependent
> libraries already installed in the default location). This is a worse
> situation than we had with the mk build system.
Not at all.
--prefix is not supposed to have anything to do with anything before
install-time, _except_ when there's the rare need for paths to be baked
in at make-time.
When you build a dist tarball, you have to make sure that the default
for --prefix is sensible, and is not the default that is useful for you
when you're working on the checkout of the software (this is the
default that you configured in when you did your top-level bootstrap).
That means either a special starconf, if you're doing it for a whole
tree, or a special acinclude.m4, if you're doing it for a single
directory.
The fact that (by my extension) the default prefix ends up somewhat
surprisingly included in -I and -L options is not a connection I'd
actually made before, and which I'm quite prepared to believe is a bad
thing. That happens because it seemed useful behaviour in the case
where you're building the whole tree -- you want the /my-star directory
containing the components you've already built to be included in the
builds to come -- but I am now not convinced it's still useful, if
indeed it ever was. It certainly does seem to be surprising (to me,
too, manifestly).
If anyone wants to do the experiment, try deleting the
`-I[]per_dir_PREFIX/include' lines at lines 170-5 of your local
buildsupport/starconf/starconf.m4.in, redo ./bootstrap --buildsupport,
and see what breaks. If nothing breaks -- whoopee! those lines are
toast.
Norman
--
----------------------------------------------------------------------
Norman Gray : Physics & Astronomy, Glasgow University, UK
http://www.astro.gla.ac.uk/users/norman/ : www.starlink.ac.uk
|