Subject: Re: net/ORBit: question regarding Makefile variable
To: Julio M. Merino Vidal <firstname.lastname@example.org>
From: Georg Schwarz <email@example.com>
Date: 03/09/2005 17:11:25
> It's in the Makefile because ORBIT_HAVE_ALLOCA_H was AC_SUBST'ed, but
> AFAICS, it's not of any use in the Makefiles.
true, but it should be.
> > config.h uses
> > #if ORBIT_HAVE_ALLOCA_H
> > #include <alloca.h>
> > #endif
> Yep, and just before that there is a '#undef ORBIT_HAVE_ALLOCA_H' line
after configuration, this line is commented out by /* */, at least on my
> (see config.h.in too). I guess the original intention was that the
> configure script could automatically modify that line to match the
> running system: i.e., set to a #define when alloca is present and
> working, or leave the #undef line otherwise.
> But they got it wrong (why am I not surprised?). AC_SUBST only sets the
> variable in the Makefiles (in fact, any output files), not in config.h.
> So the check doesn't work as expected.
That's exactly my problem.
> So one solution is, as you said, modify the CPPFLAGS in all the
> Makefile.in files to use -DORBIT_HAVE_ALLOCA_H=$(ORBIT_HAVE_ALLOCA_H);
> unfortunately, you'll probably need to modify many files in order to
> get this working (because otherwise, the inclusion of config.h in some
> subdirectories could not DTRT).
true in principle; but probably alloca() is not used in all subdirectories.
> Another solution is to modify the configure.in script to use AC_DEFINE
> and AC_SUBST for that variable. That will (hopefully) do the trick and
> set the proper value just before the #if construction you quoted, but
> I'm afraid it'd result in a big patch for configure.
seems to be best though. Unfortunately I am not familiar enough with it.
> A third solution (after a second read of the mail) is to add your
> CPPFLAGS construction from the configure script or from our package
> Makefile. This sounds like the easiest way to go.
The problem with that is that at the time this is interpreted the value
of ORBIT_HAVE_ALLOCA_H is not known.
> To make things worse, our patch-ap looks like a "broken" workaround to
> avoid this issue. Could you try, after fixing the other issue, to
> remove this one and see if everything keeps working?
I already did; and in fact I first thought that it was this patch's fault,
but after investigating more closely I think the patch is correct, because
ORBIT_HAVE_ALLOCA_H is supposed to be either 0 or 1.
> BTW, the alloca check is broken anyway: it includes alloca.h which is
> not present in NetBSD. It should only include it in case HAVE_ALLOCA_H
> is set; otherwise, use stdlib.h.
Does ORBIT_HAVE_ALLOCA_H equal 0 or 1 on NetBSD?
Georg Schwarz http://home.pages.de/~schwarz/
firstname.lastname@example.org +49 178 8545053