qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manuel Teira <mte...@tid.es>
Subject Re: autotools for examples directory
Date Wed, 11 Jun 2008 12:07:54 GMT
Alan Conway escribió:
> 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.
OK. I've added a makedist.mk makefile fragment in the examples level, 
able to generate a .libs/Makefile (in order to not conflict with the 
autotools generated one) that is eventually installed in the example 
directory. I'm mostly an autotools illiterate, so, feel free to correct 
it if you wish. autotools is just black magic for me.

Refactoring the directory structure led me to a situation where the svn 
diff is not able to illustrate the real changes. So, I've added in 
QPID-1131 all the commands needed (I hope) to recreate the new layout, 
and a patch for the new makefile stuff.
>> 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.

Also in QPID-1131 patch.

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

OK. I've added two new patches, I think that they are modular enough and 
shouldn't break anything in the linux world. Just:
QPID-1132. Adding support for the SunCC compiler.
QPID-1133. Adding the new Solaris Poller and related detections.

This is not everything needed for the solaris port to work. I have some 
include needs in some files of the project, and also some namespace 
issues. I don't think the remaining changes could break the build, my 
doubt is if they should be applied unconditionally (probably they got 
included in linux, don't know how, but they need other includes in 
Solaris) or if we should leave the #ifdef SUNOS /#endif wrapper I have 
now. Perhaps every change should be discussed separately, I don't know.

Once the patches in those JIRA issues get committed, I will try to 
cleanup everything in my repository, to see what is remaining now.

About the compiler bug with the public/private inheritance, this is what 
I have now, waiting for Steve's refactoring of that part of the code. Do 
you agree with this temporary woraround?

Index: src/qpid/sys/AsynchIO.h
--- src/qpid/sys/AsynchIO.h     (revision 663477)
+++ src/qpid/sys/AsynchIO.h     (working copy)
@@ -90,7 +90,15 @@
  * The class is implemented in terms of DispatchHandle to allow it to 
be deleted by deleting
  * the contained DispatchHandle
-class AsynchIO : private DispatchHandle {
+class AsynchIO :
+//Bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6710638
+//Should be private inheritance
+#ifdef __SUNPRO_CC   
+    public
+    private
+    DispatchHandle {
     struct BufferBase {
         char* const bytes;

Best regards.

View raw message