Subject: Re: net/ORBit: question regarding Makefile variable
To: Julio M. Merino Vidal <jmmv84@gmail.com>
From: Georg Schwarz <georg.schwarz@freenet.de>
List: tech-pkg
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
system.

> (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/
 georg.schwarz@freenet.de  +49 178 8545053