Re: [chat] portable scripting

[Pete Ryland <pdr@xxxxxx>]

On Wed, Feb 05, 2003 at 05:58:01PM +1100, Jamie Wilkinson wrote:
> This one time, at band camp, Pete Ryland wrote:
> >But then I thought the whole point of having autoconf was to be able to be
> >lame and have it do all the work.  If I have to write 100 lines of
> >compatable sh to detect for example where various python bin/include/lib/...
> >directories are (and yes, I did this the other day - and taking into account
> >possible multiple versions is a pain), then I may as well just use a shell
> >script configure instead - why can it not do this for me?  I'm sure someone
> >else will need to detect these things someday too, and I'm not in any way
> >inclined towards the copy/paste school of computer engineering.
> 
> Beacuse this way you *only* need to write the tests for the version of
> python and you don't have to worry about creating Makefiles and config.h
> and blah and blah and so on.

It was actually taking into consideration the fact that multiple versions of
python could be installed to the same prefix and allowing you to choose
which one to compile against, but that's kinda beside the point, which was
well taken.  However, in this particular case, the only thing I didn't have
to write my own checks for was broken anyway (namely the C toolchain!) and
has to be worked around on (admittedly) badly-configured machines.

> If you're really keen, break the python test into a separate m4 file, and
> distribute it.

It's only in the last week that I realised this was a done thing - there is
even a repository of the things on www.gnu.org[1], not that it's exactly
advertised (not a single mention in the goat book iirc).  However, IMO this
whole repository should be distributed/installed along with autoconf, not
just linked to as "third-party macros".

Another cool thing which I've only noticed recently (via sweep) is
pkg-config[2] which should hopefully relieve more anguish.  However, I never
understood the benefit of having a script that parsed a command line and
echoed a value, only to be interpreted into another script.  Why not just
have a script which set these as env vars which could be sourced by the
configure script (much like a lot of init.d configuration files use)?
Actually, you can already do this with autoconf's Site Config stuff[3], and
all that is needed then is that packages when installed update that script
(similarly to how Debian does modules.conf perhaps).

Pete

[1] http://www.gnu.org/software/ac-archive/
[2] http://www.freedesktop.org/software/pkgconfig/
[3] http://www.gnu.org/manual/autoconf-2.53/html_node/Site-Defaults.html
-- 
Pete Ryland
http://pdr.cx/