Calling autoconf in a spec.

[Michael Ekstrand]

On 07/15/2011 11:43 AM, Kevin Kofler wrote:
> Sam Varshavchik wrote:
>> There's a big difference between having the upstream, who knows their
>> configure script inside and out,
> 
> That's a very bold assertion. ;-) Many upstream developers just copy&paste 
> their configure.ac scripts together from examples or other projects without 
> understanding them. The current maintainer might also not be the developer 
> who wrote the scripts (who is often the only one understanding them).
> 
> Case in point: There are bazillions of projects testing for the existence of 
> standard ANSI C89 / ISO C90 (not C99, C90!) functions (which have been 
> available on every even remotely modern OS for decades) in their configure 
> scripts, then just ignoring the results of the checks and just using memcpy 
> etc. without a second thought (which makes sense because those are part of 
> an ubiquitous, 23-year-old standard, but then checking for them in configure 
> and defining unused HAVE_MEMCPY etc. booleans does NOT make sense). 
> Likewise, projects routinely check for the existence of a Fortran compiler 
> without even including a single line of Fortran.

To be fair, a lot of this is ascribable to libtool (in the output, not
in the configure.ac).  If you use libtool (which most autotooled
projects incorporating shared libraries do), the single line in
configure.ac to activate and configure libtool performs a bunch of C
checks and looks for the Fortran compiler (I've always assumed so that
it can determine whether it can/should support Fortran libraries or
client code, but have never verified this assumption).  It could be
better (e.g. looking whether AC_LANG_FORTRAN has been called and
skipping Fortran otherwise), but using Libtool generates a lot of checks
which the program itself likely doesn't use or respect.

- Michael