processing include files

[Alan DeKok]

Enrik Berkhan wrote:
> That kind of problem actually has two causes:
> 
> 1. The autoconf namespace pollution you mentioned. Avoid it where possible.

  It's difficult to avoid it when FreeRADIUS depends on other packages.

> 2. Misinterpretation of HAVE_FOO_H. IMHO, HAVE_FOO_H means, the header,
> library, package, subsystem, whatever is _available_ on this system. It
> shouldn't be used to decide if foo should be used or enabled when
> building the software.

  Why not?  Every single project using autoconf does:

#ifdef HAVE_FOO_H
#include <foo.h>
#endif

  Autoconf even recommends doing this.

> The first item can be actively adressed for FreeRADIUS by FreeRADIUS
> itself. I think the solution for generated header files discussed
> yesterday should be sufficient if it turns out to be actually working.

  I solved the problem for net-snmp by re-arranging the FreeRADIUS
header files and #include order so that their namespace pollution
doesn't affect us.

> But when the first item is not obeyed by used libraries like netsmp, the
> only solution is to make FreeRADIUS' autoconf setup more robust against
> it by implementing the second item consistently.

  There's no need.  Every other package doesn't install the "autoconf.h"
files.  In nearly a decade of working with many packages, I've only seen
this happen *once*.  It's simply not worth our time to find a "clean"
solution to a problem that is no longer a problem.

> Of course, this should only exemplify how this could be done and
> espacially the name "WITH_THREADS" should be chosen clever enough.

  To cleanly avoid namespace pollution, we'd have to prefix every symbol
with "FR_", or something like that.

> After all, it should be possible to configure --with-threads=no then, no
> matter if HAVE_PTHREADS_H is defined from anywhere.

  No.  If the software is to be built without threading support, then it
cannot even *look* for thread header files.  It can't include the thread
header files, because doing so can have side effects on many
platforms... such as making the software depend on the thread libraries.

  After some further reflection, it should be possible to write even
nicer autoconf macros.  That root through the header files to discover
what to look for, and what defines to set.

  e.g. have a file: missing-headers.h.in, that is *nothing* more than a
list of #include <foo.h>.  The autoconf macros can then process the
file, doing:

  1) finding #include <foo.h> in the input text
  2) running AC_CHECK_HEADER(foo.h)
  3) if there's no $ac_cv_header_foo_h, output: /* #include <foo.h> */
  4) if there is $ac_cv_header_foo_h, output: #define HAVE_FOO_H
     into a "missing-defines.h"
  5) and output: #include <foo.h>
     into "missing-headers.h"

  This should work for 99% of the cases FreeRADIUS uses.  It also means
we don't have to re-generate "configure" when we add a check for another
header file.  The code Just Figures It Out.

  I've never understood why autoconf has to swallow so many of the
checks into the "configure.in" file, using autoconf's arcane macros.
Why not just define 2-3 simple file formats to check for headers,
functions, libraries, etc., and let the poor application developers
avoid the whole autoconf nonsense?

  If that was done, the autoconf scripts could even become
*maintainable*.  Using autoconf could be as simple as creating an
"autoconf" directory, and dropping the autoconf scripts in it.  Then,
create a "local config" directory, and put your checks in it.  Point one
at the other, and you're done.

  There's no need for magic re-generation of 100k LoC shell scripts.
The autoconf people seem to be of the mind that it's a good ida to have
arcane complex code to auto-generate code that then auto-generates code.
 Why not just write scripts that make sense to the average human, and
have them read config files that make sense to the average human?

  Maybe I'll take a stab at it.  Autoconf is really starting to get tiring.

  Alan DeKok.