On Tue, Dec 30, 2008 at 8:55 AM, Arjen de Korte <nut+devel at de-korte.org> wrote:> While adding the tcp_wrappers support, I also noticed that in many cases we > use both WITH_FOO (usually in Makefile.am) and HAVE_FOO (mostly in the > sources). > > Note that having something available, may not mean that it should be > configured with it. So in most cases, if we conditionally compile sources, > we should be testing against WITH_FOO instead of HAVE_FOO. As far as I can > see, the HAVE_FOO stuff should be replaced almost everywhere by WITH_FOO > except in configure.in, where the prerequisites for WITH_BAR may require the > presence of both HAVE_FOO and HAVE_BAR. > > Any thoughts?Interesting, I hadn't noticed that. I wonder if it's just because packagers tend to enable almost everything? I don't have time to check into this now, but later this week I can dig up my autotools book and see if there's some other possible explanation. -- - Charles Lepple
Citeren Charles Lepple <clepple at gmail.com>:> Interesting, I hadn't noticed that. I wonder if it's just because > packagers tend to enable almost everything?It probably has to do when these are evaluated. WITH_FOO is set through AM_CONDITIONAL and is used in Makefile.am files. In contrast, HAVE_FOO is set through an AC_DEFINE and eventually ends up in the 'include/config.h' file as a C-preprocessor macro. Maybe there is no other way to do this (WITH_FOO and HAVE_FOO are both set at the same time, based on the same variable in 'configure.in'). So just replacing HAVE_FOO by WITH_FOO probably isn't going to work. Or should we handle this by creating separate objects that are linked in, depending on whether something is available or not. In that case, we wouldn't need the preprocessor macros. It would surely clean up the code a lot, although it may require lots of stub functions (which we seem to have for SSL anyway). Best regards, Arjen -- Please keep list traffic on the list