Re: automake --no-force (Was: autoreconf invode automake with --no-force (autoconf ver.2.54))

[Russ Allbery]

Nishio Futoshi <address@hidden> writes:

> My suggestion for beginers:

> Use autoscan in your source directory, then rename `configure.scan' to
> `configure.in'.  Then edit `configure.in'.  Your works are to modify
> `AC_INIT' arguments, comment out `AC_CONFIG_HEADERS', add
> AM_INIT_ATOMAKE([foreign]), and modify AC_CONFIG_FILES([Makefile]).
> And create `Makefile.am'.  First line is `bin_PROGURAMS =
> packagename', and second line is packagename_SOURCES = yoursource.c
> yourheader.h ...'.  Then run `autoreconf -sif'.  Does that sound
> difficult?

> Unfortunately, it's not for portability, but I think it's a good
> tutolial for beginers.  They can stand on start line for using
> Autotool.

It's not too bad of a way to start, but it has a drawback that I've seen
in probably the majority of Autoconf scripts out there, namely it creates
a configure.in that checks for a bunch of things for which the source code
has no workarounds or fallbacks.

I really wish it would be emphasized that putting checks for things into
configure.in without dealing with the results of those tests in the source
code is completely pointless, because *lots* of people make this mistake.
Checks get copied from configure.in to configure.in in sort of a cargo
cult portability exercise without any understanding of what the test
really does or what the implications are for the rest of the source code.
Witness the amount of code that runs AC_CHECK_HEADER on a header file and
then never uses the defined symbol anywhere in the source code.

The hard reality of the situation is that unless you're particularly
dedicated to portability and have access to some older systems on which to
test, the vast majority of stuff that autoscan finds is worthless.  The
average C programmer has absolutely no idea what to do if <unistd.h> or or
<limits.h> is missing, or what to do on a platform with the SunOS memcmp
bug.  Nor is there really any reason for them to care, since the chances
that anyone is going to compile the average free software program that
isn't make, gcc, etc. on SunOS has probably already reached the noise
levels.

-- 
Russ Allbery (address@hidden)             <http://www.eyrie.org/~eagle/>