Manuel Teira wrote:
Hello all.
Recently I was aware that the examples directory (cpp/examples) was not
even compiled using Sun provided make. Even changing to GNU make, some
assumptions (for example about linker arguments) are not valid for
SunCC, or for example some flags needed for compilation (some ifdef
SUNOS in headers) are not passed as autotools are not used.
I thought that the best option would be to migrate the examples
directory to use also autotools (so we can blame them for all our these
pains), and made so in my local copy, succeeding into compiling all the
examples. What do you think about this change? I mean, perhaps avoiding
autotools was intended for some goal I didn't catch.
As the author of that mess I agree. While we're at it we should change the
strange examples/examples/ directory structure to be just examples/.
Here's the original reasoning: The examples are designed to be installed, built
and run by a user outside of Qpids automake system. We can't impose automake as
a precursor to playing with examples or potential users will run screaming from
the room. So we'll use VERY simple, bog-standard make files and just let
automake kick off a plain make.
HOWEVER, its been painful to maintain ever since and still causes problems with
VPATH builds etc. so I conceed it was a Bad Idea.
The important thing to keep is that we must still install plain, simple
Makefiles with the examples. Hand written makefiles are likely to go out of
date, so perhaps the best thing would be to have the Makefile.am generate a file
called Makefile.install say based on the source lists actually used in
Makefile.am to build the examples. Then we install that as just Makefile.
I've also found what I think are some bashisms, constructions like:
export foo=var
are not valid in plain bourne shells, or at least they aren't using
solaris sh. As in most linux flavours, sh uses to be a link to bash, I
suppose it's something difficult to be aware of. I will get rid of those
things too.
Please do, the intention is always to write plain sh compatible scripts but
these things creep in.
My plan would be to add it to the solaris branch in Steve's git
repository, but if you prefer to detach this change from the solaris
branch effort, I could just commit a patch to the project JIRA.
I'd love it if you can put this in JIRA as this is useful refactoring generally
speaking.
In fact I'd encourage yourself and Steve to put in JIRAs for any self-contained
bit of work that won't break the trunk. Integrating early and often will be less
painful that a big-bang from git and it's good for your eventual Apache
committership to have your name on plenty of JIRAs :)
