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.