That makes sense. The source tarballs for 7.14 were generated on a
system with automake 1.6 so the prebuilt build files have the cppflags
bug. Once you ran autogen.sh it was fixed, just doubly so. :-)
I'm adding a regression test now to detect per-product cppflags since
this isn't the fir
On Wed, Nov 12, 2008 at 6:44 PM, Christopher Sean Morrison
<[EMAIL PROTECTED]> wrote:
>
> Did you run ./autogen.sh before running configure, or just run configure?
> The bombardier_CPPFLAGS have both tcl and tk flags set so if everything is
> working right and is up to date, it should be includi
Did you run ./autogen.sh before running configure, or just run configure? The
bombardier_CPPFLAGS have both tcl and tk flags set so if everything is working
right and is up to date, it should be including the dirs via that directive.
Setting AM_CPPFLAGS is sort of the shotgun approach since i
On Wed, Nov 12, 2008 at 5:57 PM, Christopher Sean Morrison
<[EMAIL PROTECTED]> wrote:
>
> Tom,
>
> Ah, that's actually a bug in automake. The rule that builds bombardier
> already had those two CPPFLAGS set but just set on that product --
> AM_CPPFLAGS sets it on all of them in that directory.
Tom,
Ah, that's actually a bug in automake. The rule that builds bombardier already
had those two CPPFLAGS set but just set on that product -- AM_CPPFLAGS sets it
on all of them in that directory. Automake 1.8 (iirc) and later don't have the
bug, but the fix is to just make it a product-spec
I noticed that my build failed when compiling ./src/util/bombardier.c
because tk.h couldn't be found.
The line (no. 146) in ./src/util/Makefile.am that reads:
AM_CPPFLAGS = ${TCL_CPPFLAGS}
was changed to:
AM_CPPFLAGS = ${TCL_CPPFLAGS} ${TK_CPPFLAGS}
After running autogen.sh and configure a
