Re: [chat] portable scripting

[Conrad Parker <conrad@xxxxxxxxxxxx>]

On Wed, Jan 29, 2003 at 10:41:24PM +0000, 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.

but that stuff _is_ the point of the PKG_CHECK etc. macros -- the
package you're building against should at least tell you that info
(where libs are installed etc.) through its own macros, if it's
installed properly. If there's nothing like that for python, write
a macro for it and submit it to aclocal's contrib section or to python.

that stuff is the first half of what autoconf can do for you.

my point is that you can use autoconf to go beyond that level of
checking -- you can diagnose improperly installed packages like the
common case of a user installing a library but not its devel package,
in which case the header files and pkgconfig description are not
installed, yet the user complains "but I've installed the library!!!".
You can use autoconf to detect this situation and politely educate the
user about how to complete their installation.

similarly you can use autoconf to detect which of various optional
components are installed. For example, in sweep we check for codecs
and allow the user to build without support for those they don't
already have installed (and tell them both how to do this, and where
to get the codecs from if they prefer).

you can also use autoconf to reconfigure your code to different API
versions. sweep uses autoconf to detect which version of libsndfile to
use, and to detect an obsolete but usable libvorbis API. If you think
this is too much of a pain, no-one's forcing you to do it, but the
alternative behaviour is to needlessly insist on bleeding edge versions of
everything, which is simply arrogant and ignores the reality of systems
aging, users not having permission to override system libraries, and
how fragile the interdependencies of libraries and apps really are.

you can't expect everyone to upgrade their systems at the same rate as
your leet development box, and you can't ask the packages you depend
on to never ever change their versioning.

people tend to have a lot of cruft on their systems, different distros
upgrade libraries at different rates, and maybe sometime libraries
aren't available on every platform. autoconf lets you detect and work
around these kinds of problems, and it allows you to do help users
to fix their systems directly at the point of failure. The alternative
is that 99.9% of users walk away silently, and you waste time repeating
howto-upgrade info to the 0.1% of users that bother to email you.

sure, in the uber-abstract world of final versions, everything just
works and you don't need to adapt to user's systems; but in the real
world those painful 100 lines of shell script are the difference between
your software being buildable or being ignored. now you get to choose
which world you target your software to :)

K.