On Wed, 2005-03-09 at 17:11 +0100, Georg Schwarz wrote:
> > 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.

No, it shouldn't, iff the config.h.in machinery worked correctly.

> > > 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.

Yep.  I think all lines starting by #undef are automatically commented
out, _unless_ the variable they refer to has been AC_DEFINEd (which
does not happen in this case).

> > 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.

But then you make maintenance harder, because whenever someone wants to
update that package will have to remember about it (in case there are
new directories; something that won't ever happen, anyway).  I mean,
this could be quite error prone.

> > 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.

All you'd have to do is, together the ORBIT_HAVE_ALLOCA_H=1 line, add
a AC_DEFINE(ORBIT_HAVE_ALLOCA_H) (assuming autoconf 2.13).  Then regen
the configure script and extract a patch (this is the most difficult
thing, as the resulting patch should be as small as possible); usually
has to be manually edited as the result of the generation is too
different from the original one.

> > 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.

It is, in the configure script.  I.e., just after the code that defines
ORBIT_HAVE_ALLOCA_H to either 0 or 1, you could perfectly use its value.
But doing it this way requires patch-ap.

So, to avoid patch-ap, just do
CPPFLAGS="$CPPFLAGS -DORBIT_HAVE_ALLOCA_H" in the configure script,
after ORBIT_HAVE_ALLOCA_H=1; this will "simulate" an AC_DEFINE, and
hopefully will just work.

Unfortunately, I'm a bit afraid about src/ORBitutil/orbit-os-config.h.in
which redefines ORBIT_HAVE_ALLOCA_H based on AC_SUBST.  But WTF, only
some warnings will appear.

> > 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.

No, it's not.  It's supposed to be defined or undefined, according to
the semantics of the config.h file.

> > 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?

It should be 1, but actually is 0 because alloca.h does not exist.

-- 
Julio M. Merino Vidal <jmmv84@gmail.com>
http://www.livejournal.com/users/jmmv/
The NetBSD Project - http://www.NetBSD.org/