... You are polluting the preprocessor symbols' with #defines. This is considered bad design.
I'm not exactly sure what you consider "bad design", but I think I
The existence of autoconf at all is clear evidence of "bad design". The fathers of Unix should have thought about portability issues 30 years ago and included a feature-based configuration mechanism as a standard part of Unix. There was a failure to think adquately far ahead. Even the POSIX guys have not managed to provide a useful solution. Instead they just made things more difficult.
Instead we continue to consume oodles of CPU cycles with huge clunky shell scripts.
Yes, I can emit a config.h with only my ACE_ #defines myself. I may end up having to do that. I'm not looking forward to it, since auto- header almost does it right automagically. It essentially forces me to come up with a similar tool, as it would be foolhardy to even try to maintain ~500 feature tests by hand.
It is not really quite as bad as that. You can clone the auto-generated config.h.in to another file name (e.g. ace_config.h.in), with the parts you don't need stripped out. Then use AC_CONFIG_HEADERS like
AC_CONFIG_HEADERS([config.h ace_config.h])
This results in a ace_config.h being generated which is similar to config.h, but with the nasty parts removed. In the Makefiles, you arrange to install ace_config.h where config.h would normally be installed.
Bob ====================================== Bob Friesenhahn bfriesen@xxxxxxxxxxxxxxxxxxx http://www.simplesystems.org/users/bfriesen
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
