You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Alan Conway <ac...@redhat.com> on 2006/12/01 08:41:29 UTC
Automake build system up and running :)
The automake build system is in, building and passing all tests :)
There is some cleanup left to do and you will get a headache on your
first commit. Check the README for details.
Steve: building on RHEL 4 is probably buggered but probably not hard
to fix. Let me know what you stumble over and I'll help get it working
again. Most likely we'll need to downgrade the autotool versions.
Jim: Some notes & questions:
Please sanity check the README: in particular are the autotool
dependencies complete?
I gather that once bootstrapped, make will take care of re-running
autoconf, automake etc as needed - is that correct?
I had to downgrade autotool versions on fedora 6 with latest updates:
- configure.ac: autoconf 2.60 => 2.59
- Makefile.am automake 1.10 => 1.9.6
I had only one problem possibly related to this: No abs_srcdir and
abs_builddir in Makefiles. Manually added to gen/Makefile.am and
tests/Makefile.am. Autoconf substitutes them but the automake template
doesn't have them.
Building with APR via brutal hacks in the Makefile.am's, should have a
proper configure-based switch (e.g. -with-apr) that tests for the lib
etc.
Things remaining to do:
- generate RPM/SRPM
- run python tests from makefile if present.
- svn ignores for generated files.
- clean gen/* and generated make/config files.
- fix hacks for choosing APR/linux build (get rid of APR in medium term)
- doxygen
- easy selection of debug/release flags.
- fix signal handling in qpidd.cpp
- sundry renaming & cleanup which I might try to slip in during the
chaos.
Philosophical question: I'm a fan of the Single Makefile approach
(http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html). Seems
to me that we could go that way with the autoconf build system, is
there any reason not to? It's not a priority, just thinking out loud.
Cheers,
Alan.
Re: Automake build system up and running :)
Posted by Alan Conway <ac...@redhat.com>.
On Mon, 2006-12-04 at 20:55 +0000, Steven Shaw wrote:
> If you guys can build me a source tarball containing ./configure I can
> see if this thing still builds on RHEL3.
Unless there's a major snag, I think it would be reasonable to lower the
versions on our dependencies to get Qpid working out of the box on an
up-to-date RHEL3.
Cheers,
Alan.
Re: Automake build system up and running :)
Posted by Steven Shaw <st...@gmail.com>.
On 04/12/06, Alan Conway <ac...@redhat.com> wrote:
> > Perhaps you could post the ./configure script. That's all I need. Or
> > perhaps commit it to svn under a sneaky name like "configure.sneaky".
>
> What do you think Jim? My instinct is to never commit generated files,
I'm hardly suggesting it as a regular way of working..
If you guys can build me a source tarball containing ./configure I can
see if this thing still builds on RHEL3.
Cheers,
Steve.
Re: Automake build system up and running :)
Posted by Jim Meyering <ji...@meyering.net>.
Alan Conway <ac...@redhat.com> wrote:
> On Mon, 2006-12-04 at 15:33 +0000, Steven Shaw wrote:
>> On 04/12/06, Jim Meyering <ji...@meyering.net> wrote:
>> > I think you said Debian. If so, you can safely use apt preferences
>> > (see man apt_preferences) to get automake, autoconf, and libtool from
>> > "unstable", which btw, doesn't deserve that name any more.
>>
>> Does that mean that it will work now with autoconf >2.59 ?
>
> It was originally working with 2.60, I downgraded to 2.59 because that's
> the latest on fedora 6. I've no objection to downgrading further, e.g.
> for RHEL 4. I don't know why you would be having trouble with a higher
> version though.
>
>> Perhaps you could post the ./configure script. That's all I need. Or
>> perhaps commit it to svn under a sneaky name like "configure.sneaky".
>
> What do you think Jim? My instinct is to never commit generated files,
That's my preference, too.
There are problems no matter which approach you take.
In the four months since I switched GNU coreutils development
to the ./bootstrap-style approach, I get the impression that
it makes the development code base more accessible to potential
participants. Before, derived files like configure, aclocal.m4,
and Makefile.in were all version-controlled, but it was too easy
to change configure.ac or a Makefile.am file and then forget to
regenerate-and-commit the associated generated files. That would
render a checked-out-copy unbuildable by average users. In addition,
there would sometimes be conflicts in those generated files due to
developers using differing versions of tools like automake and autoconf.
> but if this is likely to get in the way of contributors then perhaps we
> should consider it.
I've found that it's better to try to educate developers than
to try to accommodate inadequate build environments.
Maybe we need more detailed instructions on how to set up a proper
build environment from scratch? Or a FAQ, on things that can go wrong?
Also, for *developers*, there is little point in providing too much
backwards compatibility wrt tools like automake and autoconf.
There is no harm in requiring that they upgrade to the latest tools.
And there *is* harm in our spending time (and more importantly making
the infrastructure less modern) to backport developer-only infrastructure.
Jim
Re: Automake build system up and running :)
Posted by Alan Conway <ac...@redhat.com>.
On Mon, 2006-12-04 at 15:33 +0000, Steven Shaw wrote:
> On 04/12/06, Jim Meyering <ji...@meyering.net> wrote:
> > I think you said Debian. If so, you can safely use apt preferences
> > (see man apt_preferences) to get automake, autoconf, and libtool from
> > "unstable", which btw, doesn't deserve that name any more.
>
> Does that mean that it will work now with autoconf >2.59 ?
It was originally working with 2.60, I downgraded to 2.59 because that's
the latest on fedora 6. I've no objection to downgrading further, e.g.
for RHEL 4. I don't know why you would be having trouble with a higher
version though.
> Perhaps you could post the ./configure script. That's all I need. Or
> perhaps commit it to svn under a sneaky name like "configure.sneaky".
What do you think Jim? My instinct is to never commit generated files,
but if this is likely to get in the way of contributors then perhaps we
should consider it. We could put them under etc/ and have ./bootstrap
copy them into the correct places if the auto-stuff fails. Have to be
careful to keep them up to date of course or they'll be more of a
hindrance than a help, which is why I don't like to commit generated
files.
Cheers,
Alan.
Re: Automake build system up and running :)
Posted by Steven Shaw <st...@gmail.com>.
On 05/12/06, Alan Conway <ac...@redhat.com> wrote:
> We should create a separate examples directory for these - good tests
> don't always make good examples and vice-versa,
Yes exactly
Re: Automake build system up and running :)
Posted by Alan Conway <ac...@redhat.com>.
On Tue, 2006-12-05 at 11:38 +0000, Steven Shaw wrote:
> They used to be in a test/client directory but now are contained in
> the tests directory along with other cppunit-based tests. Also a file
> called Makefile.cppunit.examples has been removed. That was a file I
> included in the qpid-cpp-client binary distribution. The idea is to
> get users quickly started building the examples. It need more thought
> as it hard-coded the locations of boost and APR dependencies. Maybe it
> should be using autotools too!
We should create a separate examples directory for these - good tests
don't always make good examples and vice-versa, although we should also
have the examples automatically run as part of our test process of
course. I'll add a JIRA, won't get to it in the short term though so
open invitation!
Cheers,
Alan.
Re: Automake build system up and running :)
Posted by Steven Shaw <st...@gmail.com>.
On 04/12/06, Jim Meyering <ji...@meyering.net> wrote:
> http://et.redhat.com/~meyering/qpid-0.1.tar.bz2
Thanks for making this src tarball. I've had better success with it.
Here's the story:
Oh btw - I hadn't see pkg-config before. I like it. Better than having
blah-config scripts in your PATH. It would be good to include a
qpid.pc file in the src tarball.
I set up APR like so:
export PKG_CONFIG_PATH=~/local/apr-1.2.7/lib/pkgconfig
Since 1.11.4 doesn't have a pkg-config file, I downloaded cppunit-1.11.6.
PKG_CONFIG_PATH=~/local/cppunit-1.11.6/lib/pkgconfig:$PKG_CONFIG_PATH
Configure doesn't check for boost. I told it were mine was:
export CXXFLAGS="-I$HOME/local/boost-1.33.1/include/boost-1_33_1"
I created a directory structure which included amqp-8.0.xml. It went
something like:
$ mkdir -p x/qpid
$ mkdir x/qpid/specs
$ cp amqp-8.0.xml x/qpid/specs
$ mv qpid-0.1 x/qpid/cpp
$ cd x/qpid/cpp
$ ./configure --prefix ~/local/qpid-0.1
I noticed that the generated header files are included in the src
tarball so I'm not sure why it wanted to access the AMQP specification
but this got me past that hurdle.
Note that I no longer needed to use GNU Make 3.80. My RHEL3 box has
GNU Make3.79.1 which works fine now :).
There's a certain subset of the tests that I have been including in a
client-only binary distribution. Perhaps qpid-cpp developers would
consider having those in an examples directory and installed into
$prefix/examples via 'make install'. Those are:
client_test.cpp
echo_service.cpp
topic_listener.cpp
topic_publisher.cpp
They used to be in a test/client directory but now are contained in
the tests directory along with other cppunit-based tests. Also a file
called Makefile.cppunit.examples has been removed. That was a file I
included in the qpid-cpp-client binary distribution. The idea is to
get users quickly started building the examples. It need more thought
as it hard-coded the locations of boost and APR dependencies. Maybe it
should be using autotools too!
Cheers,
Steve.
Re: Automake build system up and running :)
Posted by Steven Shaw <st...@gmail.com>.
On 04/12/06, Jim Meyering <ji...@meyering.net> wrote:
> One more possibility.
> Would you please tar up and send me your gen/ directory?
> E.g., run this:
>
> tar cf - gen |gzip > gen.tar.gz
>
> Then send gen.tar.gz
Attached
Re: Automake build system up and running :)
Posted by Jim Meyering <ji...@meyering.net>.
"Steven Shaw" <st...@gmail.com> wrote:
> Sorry Jim. I complete missed it. Here it is. looks the same to me
>
> $ (cd gen && rm -f gen-src.mk; \
>> perl -ne '/^(abs_srcdir|if|else|endif|include)\b/ or print' Makefile.am \
>> | diff -u0 - Makefile.am )
> --- - 2006-12-04 22:19:37.294493000 +0000
> +++ Makefile.am 2006-12-04 22:04:21.000000000 +0000
> @@ -0,0 +1 @@
> +include gen-src.mk
> @@ -14,0 +16 @@
> +if BUILD_IN_MESSAGE_TREE
> @@ -18,0 +21 @@
> +else
> @@ -19,0 +23 @@
> +endif
> @@ -29,0 +34 @@
> +if BUILD_IN_MESSAGE_TREE
> @@ -38,0 +44 @@
> +endif
One more possibility.
Would you please tar up and send me your gen/ directory?
E.g., run this:
tar cf - gen |gzip > gen.tar.gz
Then send gen.tar.gz
Re: Automake build system up and running :)
Posted by Steven Shaw <st...@gmail.com>.
Sorry Jim. I complete missed it. Here it is. looks the same to me
$ (cd gen && rm -f gen-src.mk; \
> perl -ne '/^(abs_srcdir|if|else|endif|include)\b/ or print' Makefile.am \
> | diff -u0 - Makefile.am )
--- - 2006-12-04 22:19:37.294493000 +0000
+++ Makefile.am 2006-12-04 22:04:21.000000000 +0000
@@ -0,0 +1 @@
+include gen-src.mk
@@ -14,0 +16 @@
+if BUILD_IN_MESSAGE_TREE
@@ -18,0 +21 @@
+else
@@ -19,0 +23 @@
+endif
@@ -29,0 +34 @@
+if BUILD_IN_MESSAGE_TREE
@@ -38,0 +44 @@
+endif
Re: Automake build system up and running :)
Posted by Jim Meyering <ji...@meyering.net>.
"Steven Shaw" <st...@gmail.com> wrote:
> On 04/12/06, Jim Meyering <ji...@meyering.net> wrote:
>> So far so good. That's two of three.
>> Did your "diff" output match mine?
>
> What diff output?
The diff output in the message that asked for make and perl versions.
I'll repeat it here, adding the [...] part.
--------------------------------
What output do you get from this command (assuming you have GNU diff)?
[this is to ensure that bootstrap's "perl -ne ..." command is generating
the same intermediate output for you as for me]:
(cd gen && rm -f gen-src.mk; \
perl -ne '/^(abs_srcdir|if|else|endif|include)\b/ or print' Makefile.am \
| diff -u0 - Makefile.am )
Here's what I get:
--- - 2006-12-04 22:07:13.438724000 +0100
+++ Makefile.am 2006-12-04 19:12:36.000000000 +0100
@@ -0,0 +1 @@
+include gen-src.mk
@@ -14,0 +16 @@ timestamp: $(spec) $(java_sources) $(cxx
+if BUILD_IN_MESSAGE_TREE
@@ -18,0 +21 @@ timestamp: $(spec) $(java_sources) $(cxx
+else
@@ -19,0 +23 @@ timestamp: $(spec) $(java_sources) $(cxx
+endif
@@ -29,0 +34 @@ gen-src.mk: timestamp
+if BUILD_IN_MESSAGE_TREE
@@ -38,0 +44 @@ gen-src.mk: timestamp
+endif
Re: Automake build system up and running :)
Posted by Steven Shaw <st...@gmail.com>.
On 04/12/06, Jim Meyering <ji...@meyering.net> wrote:
> So far so good. That's two of three.
> Did your "diff" output match mine?
What diff output?
Re: Automake build system up and running :)
Posted by Steven Shaw <st...@gmail.com>.
On 04/12/06, Jim Meyering <ji...@meyering.net> wrote:
> http://et.redhat.com/~meyering/qpid-0.1.tar.bz2
Thanks. I'll try that tomorrow.
Cheers,
Steve.
Re: Automake build system up and running :)
Posted by Jim Meyering <ji...@meyering.net>.
"Steven Shaw" <st...@gmail.com> wrote:
> $ make --version
> GNU Make 3.81
>
> $ perl --version
>
> This is perl, v5.8.8 built for i486-linux-gnu-thread-multi
So far so good. That's two of three.
Did your "diff" output match mine?
Re: Automake build system up and running :)
Posted by Steven Shaw <st...@gmail.com>.
$ make --version
GNU Make 3.81
$ perl --version
This is perl, v5.8.8 built for i486-linux-gnu-thread-multi
Re: Automake build system up and running :)
Posted by Jim Meyering <ji...@meyering.net>.
"Steven Shaw" <st...@gmail.com> wrote:
> On 04/12/06, Jim Meyering <ji...@meyering.net> wrote:
>> Did you try putting a copy of libtool.m4 in $prefix/share/aclocal,
>> using the $prefix with which you installed your private copy
>> of automake?
>
> Yep. I'm getting the following at the moment:
>
> $ ./bootstrap
> + aclocal -I m4
> + autoheader
> + libtoolize --automake
> + test -d ../gentools
> + test -d ../specs
> + cd gen
> + rm -f gen-src.mk
> + perl -ne /^(abs_srcdir|if|else|endif|include)\b/ or print Makefile.am
> + pwd
> + make -f - abs_srcdir=/home/steve/External/Projects/qpid-trunk/cpp/gen
> srcdir=. gen-src.mk
> /bin/sh: AmqpClass.java: Permission denied
> /bin/sh: -cp: not found
> make: *** [timestamp] Error 127
Details! Good. That should help narrow down the problem.
Are you using GNU make? Relatively recent version? I have 3.81
What about perl? I have v5.8.8.
What output do you get from this command (assuming you have GNU diff)?
(cd gen && rm -f gen-src.mk; \
perl -ne '/^(abs_srcdir|if|else|endif|include)\b/ or print' Makefile.am \
| diff -u0 - Makefile.am )
Here's what I get:
--- - 2006-12-04 22:07:13.438724000 +0100
+++ Makefile.am 2006-12-04 19:12:36.000000000 +0100
@@ -0,0 +1 @@
+include gen-src.mk
@@ -14,0 +16 @@ timestamp: $(spec) $(java_sources) $(cxx
+if BUILD_IN_MESSAGE_TREE
@@ -18,0 +21 @@ timestamp: $(spec) $(java_sources) $(cxx
+else
@@ -19,0 +23 @@ timestamp: $(spec) $(java_sources) $(cxx
+endif
@@ -29,0 +34 @@ gen-src.mk: timestamp
+if BUILD_IN_MESSAGE_TREE
@@ -38,0 +44 @@ gen-src.mk: timestamp
+endif
[Exit 1]
If you just want to try building it (without bothering with developer
tools, here's the tarball that's built with "make dist" from a current
checked-out tree):
http://et.redhat.com/~meyering/qpid-0.1.tar.bz2
Re: Automake build system up and running :)
Posted by Steven Shaw <st...@gmail.com>.
On 04/12/06, Jim Meyering <ji...@meyering.net> wrote:
> Did you try putting a copy of libtool.m4 in $prefix/share/aclocal,
> using the $prefix with which you installed your private copy
> of automake?
Yep. I'm getting the following at the moment:
$ ./bootstrap
+ aclocal -I m4
+ autoheader
+ libtoolize --automake
+ test -d ../gentools
+ test -d ../specs
+ cd gen
+ rm -f gen-src.mk
+ perl -ne /^(abs_srcdir|if|else|endif|include)\b/ or print Makefile.am
+ pwd
+ make -f - abs_srcdir=/home/steve/External/Projects/qpid-trunk/cpp/gen
srcdir=. gen-src.mk
/bin/sh: AmqpClass.java: Permission denied
/bin/sh: -cp: not found
make: *** [timestamp] Error 127
+ cd tests
+ rm -f gen.mk
+ perl -ne /^include / or print Makefile.am
+ pwd
+ dirname /home/steve/External/Projects/qpid-trunk/cpp/tests
+ make -f - abs_srcdir=/home/steve/External/Projects/qpid-trunk/cpp gen.mk
+ automake
automake: cannot open < gen/gen-src.mk: No such file or directory
Re: Automake build system up and running :)
Posted by Jim Meyering <ji...@meyering.net>.
"Steven Shaw" <st...@gmail.com> wrote:
> On 04/12/06, Jim Meyering <ji...@meyering.net> wrote:
>> I think you said Debian. If so, you can safely use apt preferences
>> (see man apt_preferences) to get automake, autoconf, and libtool from
>> "unstable", which btw, doesn't deserve that name any more.
>
> Does that mean that it will work now with autoconf >2.59 ?
>
> I've already installed automake/autoconf from source :)
Did you try putting a copy of libtool.m4 in $prefix/share/aclocal,
using the $prefix with which you installed your private copy
of automake?
> Perhaps you could post the ./configure script. That's all I need. Or
> perhaps commit it to svn under a sneaky name like "configure.sneaky".
>
> Cheers,
> Steve.
Re: Automake build system up and running :)
Posted by Steven Shaw <st...@gmail.com>.
On 04/12/06, Jim Meyering <ji...@meyering.net> wrote:
> I think you said Debian. If so, you can safely use apt preferences
> (see man apt_preferences) to get automake, autoconf, and libtool from
> "unstable", which btw, doesn't deserve that name any more.
Does that mean that it will work now with autoconf >2.59 ?
I've already installed automake/autoconf from source :)
Perhaps you could post the ./configure script. That's all I need. Or
perhaps commit it to svn under a sneaky name like "configure.sneaky".
Cheers,
Steve.
Re: Automake build system up and running :)
Posted by Jim Meyering <ji...@meyering.net>.
"Steven Shaw" <st...@gmail.com> wrote:
> On 04/12/06, Jim Meyering <ji...@meyering.net> wrote:
>> The problem is that your aclocal installation isn't finding libtool.m4.
>> That may happen if you install/run your own version of autoconf (which
>> contains aclocal). When aclocal runs properly, it puts a copy of
>> the AC_PROG_LIBTOOL macro in the aclocal.m4 that it creates.
>
> I had to install my own autoconf because the one I had didn't work.
> The aclocal comes from automake IIRC. I had to install a specific
Oops. Right. aclocal is from auto*make*, not autoconf <blush>
> version of automake too. Is it that the automake doesn't know where to
> look for the autoconf files?
>
>> If my guess is right, and in addition, you have a new enough
>> distro-supplied version of autoconf installed, then running
>> bootstrap like this might get you past the hump:
>>
>> env PATH=/bin:/usr/bin ./bootstrap
>
> Unfortunately my distros tools aren't the right version. I installed
> my own versions of automake and autoconf to get over the humps. This
> will defeat the purpose :)
I think you said Debian. If so, you can safely use apt preferences
(see man apt_preferences) to get automake, autoconf, and libtool from
"unstable", which btw, doesn't deserve that name any more.
Re: Automake build system up and running :)
Posted by Steven Shaw <st...@gmail.com>.
On 04/12/06, Jim Meyering <ji...@meyering.net> wrote:
> The problem is that your aclocal installation isn't finding libtool.m4.
> That may happen if you install/run your own version of autoconf (which
> contains aclocal). When aclocal runs properly, it puts a copy of
> the AC_PROG_LIBTOOL macro in the aclocal.m4 that it creates.
I had to install my own autoconf because the one I had didn't work.
The aclocal comes from automake IIRC. I had to install a specific
version of automake too. Is it that the automake doesn't know where to
look for the autoconf files?
> If my guess is right, and in addition, you have a new enough
> distro-supplied version of autoconf installed, then running
> bootstrap like this might get you past the hump:
>
> env PATH=/bin:/usr/bin ./bootstrap
Unfortunately my distros tools aren't the right version. I installed
my own versions of automake and autoconf to get over the humps. This
will defeat the purpose :)
> That runs only the system-supplied versions of the tools.
> Alternatively, you could copy libtool's libtool.m4 file into
> a directory where your autoconf tools (aclocal) will find it,
> e.g., cp libtool.m4 $prefix/share/aclocal/
> where $prefix is whatever you used when configuring autoconf.
> If you used no prefix, then use prefix=/usr/local.
I'll try this as soon as I get home.
Cheers,
Steve.
Re: Automake build system up and running :)
Posted by Jim Meyering <ji...@meyering.net>.
"Steven Shaw" <st...@gmail.com> wrote:
> I'm trying to generate a ./configure script. Here's what happens with aclocal:
...
> i.e. autoconf 2.60 and 2.59 don't seem to work. They don't have
> AC_PROG_LIBTOOL defined.
>
> So there seems to be a problem with libtool. Do I need a particular
> version installed to make autoconf happy?
The problem is that your aclocal installation isn't finding libtool.m4.
That may happen if you install/run your own version of autoconf (which
contains aclocal). When aclocal runs properly, it puts a copy of
the AC_PROG_LIBTOOL macro in the aclocal.m4 that it creates.
If my guess is right, and in addition, you have a new enough
distro-supplied version of autoconf installed, then running
bootstrap like this might get you past the hump:
env PATH=/bin:/usr/bin ./bootstrap
That runs only the system-supplied versions of the tools.
Alternatively, you could copy libtool's libtool.m4 file into
a directory where your autoconf tools (aclocal) will find it,
e.g., cp libtool.m4 $prefix/share/aclocal/
where $prefix is whatever you used when configuring autoconf.
If you used no prefix, then use prefix=/usr/local.
Jim
Re: Automake build system up and running :)
Posted by Steven Shaw <st...@gmail.com>.
I'm trying to generate a ./configure script. Here's what happens with aclocal:
---
$ /usr/bin/aclocal --version
aclocal (GNU automake) 1.4-p6
Copyright (C) 1999, 2001 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Tom Tromey <tr...@redhat.com>
$ /usr/bin/aclocal -I m4
aclocal: configure.ac: 24: macro `AM_PROG_CC_C_O' not found in library
---
So I upgraded my automake to 1.9.6 and aclocal appears to complete successfully:
---
$ aclocal --version
aclocal (GNU automake) 1.9.6
Written by Tom Tromey <tr...@redhat.com>
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ aclocal -I m4
---
I added "set -x" to bootstrap. I also installed autoconf 2.59. I get
this from bootstrap:
---
$ ./bootstrap
+ aclocal -I m4
+ autoheader
+ libtoolize --automake
+ cd tests
+ rm -f gen.mk
+ perl -ne /^include / or print Makefile.am
+ pwd
+ dirname /home/steve/External/Projects/qpid-trunk/cpp/tests
+ make -f - abs_srcdir=/home/steve/External/Projects/qpid-trunk/cpp gen.mk
( \
for i in client_test echo_service topic_listener
topic_publisher; do \
echo ${i}_SOURCES = $i.cpp; \
echo ${i}_LDADD = '$(lib_client) $(lib_common) $(extra_libs)'; \
done; \
libs=; \
for i in AccumulatedAckTest ChannelTest ConfigurationTest
ExchangeTest HeadersExchangeTest InMemoryContentTest
LazyLoadedContentTest MessageBuilderTest MessageTest QueueRegistryTest
QueueTest TopicExchangeTest TxAckTest TxBufferTest TxPublishTest
ValueTest BodyHandlerTest FieldTableTest FramingTest HeaderTest
ExceptionTest; do \
libs="$libs ${i}.la"; \
echo ${i}_la_SOURCES = $i.cpp; \
echo ${i}_la_LIBADD = '$(lib_common)'; \
echo ${i}_la_LIBADD += '$(lib_broker) $(extra_libs)'; \
echo ${i}_la_LDFLAGS = "-module -rpath `pwd`"; \
done; \
echo "check_LTLIBRARIES =$libs"; \
) \
> gen.mk-t
mv gen.mk-t gen.mk
+ automake
lib/broker/Makefile.am:9: Libtool library used but `LIBTOOL' is undefined
lib/broker/Makefile.am:9:
lib/broker/Makefile.am:9: The usual way to define `LIBTOOL' is to add
`AC_PROG_LIBTOOL'
lib/broker/Makefile.am:9: to `configure.ac' and run `aclocal' and
`autoconf' again.
lib/client/Makefile.am:9: Libtool library used but `LIBTOOL' is undefined
lib/client/Makefile.am:9:
lib/client/Makefile.am:9: The usual way to define `LIBTOOL' is to add
`AC_PROG_LIBTOOL'
lib/client/Makefile.am:9: to `configure.ac' and run `aclocal' and
`autoconf' again.
lib/common/Makefile.am:43: Libtool library used but `LIBTOOL' is undefined
lib/common/Makefile.am:43:
lib/common/Makefile.am:43: The usual way to define `LIBTOOL' is to add
`AC_PROG_LIBTOOL'
lib/common/Makefile.am:43: to `configure.ac' and run `aclocal' and
`autoconf' again.
tests/gen.mk:93: Libtool library used but `LIBTOOL' is undefined
tests/gen.mk:93:
tests/gen.mk:93: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
tests/gen.mk:93: to `configure.ac' and run `aclocal' and `autoconf' again.
tests/Makefile.am:80: `tests/gen.mk' included from here
---
If I try "autoconf" by itself I get the following:
---
$ /usr/bin/autoconf --version
autoconf (GNU Autoconf) 2.60
Written by David J. MacKenzie and Akim Demaille.
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ /usr/bin/autoconf
configure.ac:62: error: possibly undefined macro: AC_PROG_LIBTOOL
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
$ autoconf --version
autoconf (GNU Autoconf) 2.59
Written by David J. MacKenzie and Akim Demaille.
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ autoconf
configure.ac:62: error: possibly undefined macro: AC_PROG_LIBTOOL
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
$
---
i.e. autoconf 2.60 and 2.59 don't seem to work. They don't have
AC_PROG_LIBTOOL defined.
So there seems to be a problem with libtool. Do I need a particular
version installed to make autoconf happy?
This is my libtool version:
---
$ libtool --version
ltmain.sh (GNU libtool) 1.5.22 Debian 1.5.22-4 (1.1220.2.365
2005/12/18 22:14:06)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
---
Cheers,
Steve.
Re: Automake build system up and running :)
Posted by Jim Meyering <ji...@meyering.net>.
It looks like the following part of a recent patch set didn't make it:
(again, watch out for the trailing blanks)
2006-12-01 Jim Meyering <ji...@meyering.net>
* tests/Makefile.am (gen.mk): Use $$pwd, rather than $(abs_builddir),
so this file works with automake older than 1.10.
(AM_CXXFLAGS): Don't add -DUSE_APR=1 here.
Index: tests/Makefile.am
===================================================================
--- tests/Makefile.am (revision 481262)
+++ tests/Makefile.am (working copy)
@@ -1,17 +1,14 @@
-# TODO aconway 2006-11-30: nasty hack, should be done by automake?
-abs_builddir = @abs_builddir@
+AM_CXXFLAGS = $(WARNING_CFLAGS)
+INCLUDES = \
+ -I$(top_srcdir)/gen \
+ -I$(top_srcdir)/lib \
+ -I$(top_srcdir)/lib/client \
+ -I$(top_srcdir)/lib/broker \
+ -I$(top_srcdir)/lib/common \
+ -I$(top_srcdir)/lib/common/sys \
+ -I$(top_srcdir)/lib/common/framing \
+ $(APR_CXXFLAGS)
-AM_CXXFLAGS = $(WARNING_CFLAGS) -DUSE_APR=1
-INCLUDES = \
- -I$(shell apr-1-config --includedir) \
- -I$(top_srcdir)/gen \
- -I$(top_srcdir)/lib \
- -I$(top_srcdir)/lib/client \
- -I$(top_srcdir)/lib/broker \
- -I$(top_srcdir)/lib/common \
- -I$(top_srcdir)/lib/common/sys \
- -I$(top_srcdir)/lib/common/framing
-
# FIXME: -lcppunit must come from autoconf
# FIXME: have e.g., topicall, run as part of "make check"?
@@ -63,7 +60,7 @@
unit_tests = \
$(broker_tests) \
$(framing_tests) \
- $(misc_tests)
+ $(misc_tests)
noinst_PROGRAMS = $(client_tests)
@@ -77,15 +74,16 @@
# TODO aconway 2006-12-01: Should also check for qpidd.
run-python-tests: $(check_LTLIBRARIES)
../src/qpidd > qpidd.log 2>&1 &
- cd ../../python ; ./run-tests -v -I cpp_failing.txt
+ cd ../../python ; ./run-tests -v -I cpp_failing.txt
include gen.mk
+abs_builddir = @abs_builddir@
extra_libs = -lcppunit
-lib_client = ../lib/client/libclient.la
-lib_common = ../lib/common/libcommon.la
-lib_broker = ../lib/broker/libbroker.la
+lib_client = $(abs_builddir)/../lib/client/libclient.la
+lib_common = $(abs_builddir)/../lib/common/libcommon.la
+lib_broker = $(abs_builddir)/../lib/broker/libbroker.la
gen.mk: Makefile.am
( \
@@ -94,12 +92,13 @@
echo $${i}_LDADD = '$$(lib_client) $$(lib_common) $$(extra_libs)'; \
done; \
libs=; \
+ pwd=`pwd`; \
for i in $(unit_tests); do \
libs="$$libs $${i}.la"; \
echo $${i}_la_SOURCES = $$i.cpp; \
echo $${i}_la_LIBADD = '$$(lib_common)'; \
echo $${i}_la_LIBADD += '$$(lib_broker) $$(extra_libs)'; \
- echo $${i}_la_LDFLAGS = '-module -rpath $$(abs_builddir)'; \
+ echo $${i}_la_LDFLAGS = '-module -rpath $$pwd'; \
done; \
echo "check_LTLIBRARIES =$$libs"; \
) \
Re: Automake build system up and running :)
Posted by Jim Meyering <ji...@meyering.net>.
Alan Conway <ac...@redhat.com> wrote:
...
> Things remaining to do:
...
> - svn ignores for generated files.
This gets most of them.
But it's not easy to test (at least not with svn directly -- anyone know
of a way?), so I may have missed a few.
I'll write a rule to update the list in gen/.svnignore automatically.
2006-12-01 Jim Meyering <me...@redhat.com>
Ignore generated files.
* gen/.svnignore, lib/broker/.svnignore, lib/client/.svnignore:
* lib/common/.svnignore, src/.svnignore, tests/.svnignore, .svnignore:
2006-12-01 Jim Meyering <ji...@meyering.net>
Index: gen/.svnignore
===================================================================
--- gen/.svnignore (revision 0)
+++ gen/.svnignore (revision 0)
@@ -0,0 +1,101 @@
+AMQP_ClientOperations.h
+AMQP_ClientProxy.cpp
+AMQP_ClientProxy.h
+AMQP_Constants.h
+AMQP_MethodVersionMap.cpp
+AMQP_MethodVersionMap.h
+AMQP_ServerOperations.h
+AMQP_ServerProxy.cpp
+AMQP_ServerProxy.h
+AccessRequestBody.h
+AccessRequestOkBody.h
+BasicAckBody.h
+BasicCancelBody.h
+BasicCancelOkBody.h
+BasicConsumeBody.h
+BasicConsumeOkBody.h
+BasicDeliverBody.h
+BasicGetBody.h
+BasicGetEmptyBody.h
+BasicGetOkBody.h
+BasicPublishBody.h
+BasicQosBody.h
+BasicQosOkBody.h
+BasicRecoverBody.h
+BasicRejectBody.h
+BasicReturnBody.h
+ChannelAlertBody.h
+ChannelCloseBody.h
+ChannelCloseOkBody.h
+ChannelFlowBody.h
+ChannelFlowOkBody.h
+ChannelOpenBody.h
+ChannelOpenOkBody.h
+ConnectionCloseBody.h
+ConnectionCloseOkBody.h
+ConnectionOpenBody.h
+ConnectionOpenOkBody.h
+ConnectionRedirectBody.h
+ConnectionSecureBody.h
+ConnectionSecureOkBody.h
+ConnectionStartBody.h
+ConnectionStartOkBody.h
+ConnectionTuneBody.h
+ConnectionTuneOkBody.h
+DtxSelectBody.h
+DtxSelectOkBody.h
+DtxStartBody.h
+DtxStartOkBody.h
+ExchangeDeclareBody.h
+ExchangeDeclareOkBody.h
+ExchangeDeleteBody.h
+ExchangeDeleteOkBody.h
+FileAckBody.h
+FileCancelBody.h
+FileCancelOkBody.h
+FileConsumeBody.h
+FileConsumeOkBody.h
+FileDeliverBody.h
+FileOpenBody.h
+FileOpenOkBody.h
+FilePublishBody.h
+FileQosBody.h
+FileQosOkBody.h
+FileRejectBody.h
+FileReturnBody.h
+FileStageBody.h
+Makefile
+Makefile.in
+QueueBindBody.h
+QueueBindOkBody.h
+QueueDeclareBody.h
+QueueDeclareOkBody.h
+QueueDeleteBody.h
+QueueDeleteOkBody.h
+QueuePurgeBody.h
+QueuePurgeOkBody.h
+StreamCancelBody.h
+StreamCancelOkBody.h
+StreamConsumeBody.h
+StreamConsumeOkBody.h
+StreamDeliverBody.h
+StreamPublishBody.h
+StreamQosBody.h
+StreamQosOkBody.h
+StreamReturnBody.h
+TestContentBody.h
+TestContentOkBody.h
+TestIntegerBody.h
+TestIntegerOkBody.h
+TestStringBody.h
+TestStringOkBody.h
+TestTableBody.h
+TestTableOkBody.h
+TunnelRequestBody.h
+TxCommitBody.h
+TxCommitOkBody.h
+TxRollbackBody.h
+TxRollbackOkBody.h
+TxSelectBody.h
+TxSelectOkBody.h
+timestamp
Index: lib/broker/.svnignore
===================================================================
--- lib/broker/.svnignore (revision 0)
+++ lib/broker/.svnignore (revision 0)
@@ -0,0 +1,4 @@
+.deps
+.libs
+Makefile
+Makefile.in
Index: lib/client/.svnignore
===================================================================
--- lib/client/.svnignore (revision 0)
+++ lib/client/.svnignore (revision 0)
@@ -0,0 +1,4 @@
+.deps
+.libs
+Makefile
+Makefile.in
Index: lib/common/.svnignore
===================================================================
--- lib/common/.svnignore (revision 0)
+++ lib/common/.svnignore (revision 0)
@@ -0,0 +1,4 @@
+.deps
+.libs
+Makefile
+Makefile.in
Index: src/.svnignore
===================================================================
--- src/.svnignore (revision 0)
+++ src/.svnignore (revision 0)
@@ -0,0 +1,3 @@
+.deps
+Makefile
+Makefile.in
Index: tests/.svnignore
===================================================================
--- tests/.svnignore (revision 0)
+++ tests/.svnignore (revision 0)
@@ -0,0 +1,4 @@
+.deps
+Makefile
+Makefile.in
+gen.mk
Index: .svnignore
===================================================================
--- .svnignore (revision 0)
+++ .svnignore (revision 0)
@@ -0,0 +1,9 @@
+Makefile
+Makefile.in
+aclocal.m4
+autom4te.cache
+config.h
+config.log
+config.status
+configure
+stamp-h1
Re: better bootstrap and gen/* dependencies
Posted by Jim Meyering <ji...@meyering.net>.
Alan Conway <ac...@redhat.com> wrote:
> Jim I had problems with this - where are $JAVA and $JAVAC supposed to be
> set? I've got to go, I'll apply the patch tomorrow unless Gordon beats
> me to it.
Alan,
Those variables are set via configure. The AC_CHECK_PROGS autoconf macro
AC_SUBST's them. I've verified that the patch applies to a tree with no
modifications and that a subsequent "make" reruns autoconf, configure et
al (checking for java and javac) and rebuilds all of the required pieces.
What symptoms do you have?
> On Fri, 2006-12-01 at 21:32 +0100, Jim Meyering wrote:
>> This changes gives qpid improved dependency tracking: Now, if someone
>> modifies one of the gentools/... .java or .tmpl files, the source files
>> in gen/ will be regenerated. But only if java and javac are available
>> and this is not a stand-alone qpid-cpp directory.
>>
>> Also with this change, you should be able to "svn remove" the
>> generated file, gen/gen-src.mk, since the modified bootstrap
>> script generates it up front.
>>
>> 2006-12-01 Jim Meyering <me...@redhat.com>
>>
>> * configure.ac: Use an automake conditional to indicate when we
>> have access to files outside of the current hierarchy, and when
>> we have the tools (java and javac) to build some generated files.
>> * gen/Makefile.am: Don't use $(abs_srcdir); not needed.
>> (timestamp): Depend on java sources and C++ template files,
>> if we're building in a qpid tree.
>> Use $(JAVA) and $(JAVAC), rather than hard-coding those names.
>> (gen-src.mk) [$(java_sources), $(cxx_templates)]: New rules to
>> generate these lists of file names.
>>
>> * bootstrap: Also generate gen/gen-src.mk.
>> But do that only if we're in a qpid hierarchy.
>> Redirect make's stdout to /dev/null.
Re: better bootstrap and gen/* dependencies
Posted by Alan Conway <ac...@redhat.com>.
Jim I had problems with this - where are $JAVA and $JAVAC supposed to be
set? I've got to go, I'll apply the patch tomorrow unless Gordon beats
me to it.
On Fri, 2006-12-01 at 21:32 +0100, Jim Meyering wrote:
> This changes gives qpid improved dependency tracking: Now, if someone
> modifies one of the gentools/... .java or .tmpl files, the source files
> in gen/ will be regenerated. But only if java and javac are available
> and this is not a stand-alone qpid-cpp directory.
>
> Also with this change, you should be able to "svn remove" the
> generated file, gen/gen-src.mk, since the modified bootstrap
> script generates it up front.
>
> 2006-12-01 Jim Meyering <me...@redhat.com>
>
> * configure.ac: Use an automake conditional to indicate when we
> have access to files outside of the current hierarchy, and when
> we have the tools (java and javac) to build some generated files.
> * gen/Makefile.am: Don't use $(abs_srcdir); not needed.
> (timestamp): Depend on java sources and C++ template files,
> if we're building in a qpid tree.
> Use $(JAVA) and $(JAVAC), rather than hard-coding those names.
> (gen-src.mk) [$(java_sources), $(cxx_templates)]: New rules to
> generate these lists of file names.
>
> * bootstrap: Also generate gen/gen-src.mk.
> But do that only if we're in a qpid hierarchy.
> Redirect make's stdout to /dev/null.
>
> Index: configure.ac
> ===================================================================
> --- configure.ac (revision 481343)
> +++ configure.ac (working copy)
> @@ -33,6 +33,19 @@
> esac],
> [enableval=yes])
>
> +# Turn on this automake conditional if we are in a qpid
> +# hierarchy (i.e. with gentools/ and specs/ sibling directories),
> +# and if we have working java + javac.
> +build=yes
> +AC_CHECK_PROGS([JAVA], [java], [no])
> +AC_CHECK_PROGS([JAVAC], [javac], [no])
> +build=yes
> +test x$JAVA = xno && build=no
> +test x$JAVAC = xno && build=no
> +test -d $srcdir/../gentools || build=no
> +test -d $srcdir/../specs || build=no
> +AM_CONDITIONAL([BUILD_IN_MESSAGE_TREE], [test x$build = xyes])
> +
> # Warnings: Enable as many as possible, keep the code clean. Please
> # do not disable warnings or remove -Werror without discussing on
> # qpid-dev list.
> Index: gen/Makefile.am
> ===================================================================
> --- gen/Makefile.am (revision 481343)
> +++ gen/Makefile.am (working copy)
> @@ -1,6 +1,3 @@
> -# TODO aconway 2006-11-30: nasty hack, should be done by automake?
> -abs_srcdir = @abs_srcdir@
> -
> include gen-src.mk
>
> BUILT_SOURCES = $(generated_sources)
> @@ -10,21 +7,20 @@
> EXTRA_DIST = $(BUILT_SOURCES)
> MAINTAINERCLEANFILES = $(BUILT_SOURCES)
>
> -gentools_dir = $(abs_srcdir)/../../gentools
> -spec_dir = $(abs_srcdir)/../../specs
> +gentools_dir = $(srcdir)/../../gentools
> +spec_dir = $(srcdir)/../../specs
> spec = $(spec_dir)/amqp-8.0.xml
> +gentools_srcdir = $(gentools_dir)/src/org/apache/qpid/gentools
>
> -# FIXME: add dependencies?
> -timestamp: $(spec)
> - if test -d $(gentools_dir); then \
> - rm -f $(generated_sources); \
> - (cd $(gentools_dir)/src/org/apache/qpid/gentools && \
> - rm -f *.class && javac *.java); \
> - java -cp $(gentools_dir)/src org.apache.qpid.gentools.Main \
> - -c -o . -t $(gentools_dir)/templ.cpp $(spec); \
> - else \
> - echo "warning: failed to regenerate gen/*.{cpp,h}" 1>&2; \
> - fi
> +timestamp: $(spec) $(java_sources) $(cxx_templates)
> +if BUILD_IN_MESSAGE_TREE
> + rm -f $(generated_sources)
> + (cd $(gentools_srcdir) && rm -f *.class && $(JAVAC) *.java); \
> + $(JAVA) -cp $(gentools_dir)/src org.apache.qpid.gentools.Main \
> + -c -o . -t $(gentools_dir)/templ.cpp $(spec)
> +else
> + echo "warning: failed to regenerate gen/*.{cpp,h}" 1>&2
> +endif
> touch timestamp
>
> EXTRA_DIST += timestamp
> @@ -35,4 +31,14 @@
> ( echo 'generated_sources = \' \
> && ls *.cpp *.h | sort -u | sed 's/.*/ & \\/;$$s/ \\//' \
> ) > $@-t
> +if BUILD_IN_MESSAGE_TREE
> + ( echo 'java_sources = \' \
> + && find $(gentools_srcdir) -name '*.java' \
> + | sort -u | sed 's/.*/ & \\/;$$s/ \\//' \
> + ) >> $@-t
> + ( echo 'cxx_templates = \' \
> + && find $(gentools_dir)/templ.cpp -name '*.tmpl' \
> + | sort -u | sed 's/.*/ & \\/;$$s/ \\//' \
> + ) >> $@-t
> +endif
> mv $@-t $@
> Index: bootstrap
> ===================================================================
> --- bootstrap (revision 481343)
> +++ bootstrap (working copy)
> @@ -4,10 +4,19 @@
> autoheader
> libtoolize --automake
>
> +# If we're building in the qpid tree, we can generate
> +# some Makefile snippets:
> +
> +if test -d ../gentools && test -d ../specs; then
> + (cd gen && rm -f gen-src.mk
> + perl -ne '/^(abs_srcdir|if|else|endif|include)\b/ or print' Makefile.am \
> + | make -f - abs_srcdir=`pwd` srcdir=. gen-src.mk > /dev/null )
> +fi
> +
> # Generate (for automake) lots of repetitive parts of tests/Makefile.am.
> (cd tests && rm -f gen.mk
> perl -ne '/^include / or print' Makefile.am \
> - | make -f - abs_srcdir=`dirname $(pwd)` gen.mk )
> + | make -f - abs_srcdir=`dirname $(pwd)` gen.mk > /dev/null )
>
> automake
> autoconf
better bootstrap and gen/* dependencies
Posted by Jim Meyering <ji...@meyering.net>.
This changes gives qpid improved dependency tracking: Now, if someone
modifies one of the gentools/... .java or .tmpl files, the source files
in gen/ will be regenerated. But only if java and javac are available
and this is not a stand-alone qpid-cpp directory.
Also with this change, you should be able to "svn remove" the
generated file, gen/gen-src.mk, since the modified bootstrap
script generates it up front.
2006-12-01 Jim Meyering <me...@redhat.com>
* configure.ac: Use an automake conditional to indicate when we
have access to files outside of the current hierarchy, and when
we have the tools (java and javac) to build some generated files.
* gen/Makefile.am: Don't use $(abs_srcdir); not needed.
(timestamp): Depend on java sources and C++ template files,
if we're building in a qpid tree.
Use $(JAVA) and $(JAVAC), rather than hard-coding those names.
(gen-src.mk) [$(java_sources), $(cxx_templates)]: New rules to
generate these lists of file names.
* bootstrap: Also generate gen/gen-src.mk.
But do that only if we're in a qpid hierarchy.
Redirect make's stdout to /dev/null.
Index: configure.ac
===================================================================
--- configure.ac (revision 481343)
+++ configure.ac (working copy)
@@ -33,6 +33,19 @@
esac],
[enableval=yes])
+# Turn on this automake conditional if we are in a qpid
+# hierarchy (i.e. with gentools/ and specs/ sibling directories),
+# and if we have working java + javac.
+build=yes
+AC_CHECK_PROGS([JAVA], [java], [no])
+AC_CHECK_PROGS([JAVAC], [javac], [no])
+build=yes
+test x$JAVA = xno && build=no
+test x$JAVAC = xno && build=no
+test -d $srcdir/../gentools || build=no
+test -d $srcdir/../specs || build=no
+AM_CONDITIONAL([BUILD_IN_MESSAGE_TREE], [test x$build = xyes])
+
# Warnings: Enable as many as possible, keep the code clean. Please
# do not disable warnings or remove -Werror without discussing on
# qpid-dev list.
Index: gen/Makefile.am
===================================================================
--- gen/Makefile.am (revision 481343)
+++ gen/Makefile.am (working copy)
@@ -1,6 +1,3 @@
-# TODO aconway 2006-11-30: nasty hack, should be done by automake?
-abs_srcdir = @abs_srcdir@
-
include gen-src.mk
BUILT_SOURCES = $(generated_sources)
@@ -10,21 +7,20 @@
EXTRA_DIST = $(BUILT_SOURCES)
MAINTAINERCLEANFILES = $(BUILT_SOURCES)
-gentools_dir = $(abs_srcdir)/../../gentools
-spec_dir = $(abs_srcdir)/../../specs
+gentools_dir = $(srcdir)/../../gentools
+spec_dir = $(srcdir)/../../specs
spec = $(spec_dir)/amqp-8.0.xml
+gentools_srcdir = $(gentools_dir)/src/org/apache/qpid/gentools
-# FIXME: add dependencies?
-timestamp: $(spec)
- if test -d $(gentools_dir); then \
- rm -f $(generated_sources); \
- (cd $(gentools_dir)/src/org/apache/qpid/gentools && \
- rm -f *.class && javac *.java); \
- java -cp $(gentools_dir)/src org.apache.qpid.gentools.Main \
- -c -o . -t $(gentools_dir)/templ.cpp $(spec); \
- else \
- echo "warning: failed to regenerate gen/*.{cpp,h}" 1>&2; \
- fi
+timestamp: $(spec) $(java_sources) $(cxx_templates)
+if BUILD_IN_MESSAGE_TREE
+ rm -f $(generated_sources)
+ (cd $(gentools_srcdir) && rm -f *.class && $(JAVAC) *.java); \
+ $(JAVA) -cp $(gentools_dir)/src org.apache.qpid.gentools.Main \
+ -c -o . -t $(gentools_dir)/templ.cpp $(spec)
+else
+ echo "warning: failed to regenerate gen/*.{cpp,h}" 1>&2
+endif
touch timestamp
EXTRA_DIST += timestamp
@@ -35,4 +31,14 @@
( echo 'generated_sources = \' \
&& ls *.cpp *.h | sort -u | sed 's/.*/ & \\/;$$s/ \\//' \
) > $@-t
+if BUILD_IN_MESSAGE_TREE
+ ( echo 'java_sources = \' \
+ && find $(gentools_srcdir) -name '*.java' \
+ | sort -u | sed 's/.*/ & \\/;$$s/ \\//' \
+ ) >> $@-t
+ ( echo 'cxx_templates = \' \
+ && find $(gentools_dir)/templ.cpp -name '*.tmpl' \
+ | sort -u | sed 's/.*/ & \\/;$$s/ \\//' \
+ ) >> $@-t
+endif
mv $@-t $@
Index: bootstrap
===================================================================
--- bootstrap (revision 481343)
+++ bootstrap (working copy)
@@ -4,10 +4,19 @@
autoheader
libtoolize --automake
+# If we're building in the qpid tree, we can generate
+# some Makefile snippets:
+
+if test -d ../gentools && test -d ../specs; then
+ (cd gen && rm -f gen-src.mk
+ perl -ne '/^(abs_srcdir|if|else|endif|include)\b/ or print' Makefile.am \
+ | make -f - abs_srcdir=`pwd` srcdir=. gen-src.mk > /dev/null )
+fi
+
# Generate (for automake) lots of repetitive parts of tests/Makefile.am.
(cd tests && rm -f gen.mk
perl -ne '/^include / or print' Makefile.am \
- | make -f - abs_srcdir=`dirname $(pwd)` gen.mk )
+ | make -f - abs_srcdir=`dirname $(pwd)` gen.mk > /dev/null )
automake
autoconf