Alan DeKok schrieb:

That has my vote. Except that last I checked, autoconf doesn't process header files. So some other method has to be used.

Have you tried to declare AM_CONFIG_HEADER(include/freeradius-client.h) in configure.in like for config.h, rename freeradius-client.h to freeradius-client.h.in and add the specific defines at the top like autoheader would to for config.h? Like this: freeradius-client.h.in: ... #undef HAVE_INTTYPES_H #undef HAVE_STDINT_H ... #ifdef HAVE_INTTYPES_H #include <inttypes.h> #endif #ifdef HAVE_STDINT_H #include <stdint.h> #endif I think maintaining a small number of #undef templates manually should be no big deal. Running configure will replace the #undef templates with the appropriate values. The only problem with freeradius-client.h currently would be the use of other #undef directives with the __BEGIN_DECLS stuff. configure will comment them out. May be it would be possible to implement the C++ extern declaration in another way ... Or distribute a second (config) header freeradius-clientconfig.h included by freeradius-client.h, but never ever name it autoconf.h. Enrik

Enrik Berkhan wrote:

Wichert Akkerman wrote:

...

Doesn't AC_CONFIG(include/freeradius-client.h) work? There is no special logic in autoconf that checks file types as far as I know.

I think this works without polluting any namespace.

If that works, great. Last I looked (a while ago), this didn't seem possible.

configure.in:

AC_CHECK_HEADERS(inttypes.h, [INCLUDE_INTTYPES='#include <inttypes.h>'], [INCLUDE_INTTYPES='/* inttypes.h not available on this system */']) AC_CHECK_HEADERS(stdint.h, [INCLUDE_STDINT='#include <stdint.h>'], [INCLUDE_STDINT='/* stdint.h not available on this system */']) AC_SUBST(INCLUDE_INTTYPES) AC_SUBST(INCLUDE_STDINT)

That's a whole lot saner than the "autoconf.h" and "#ifdef HAVE_FOO" nonsense we use right now. I'll see if I can wrap a macro around that example, so there's even less typing to do: AC_NON_STUPID_CHECK_HEADERS(inttypes.h, stdint.h) --> defines HAVE_*, INCLUDE_*, etc. 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.