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.
Done.
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
+#else
+ private
+#endif
+ DispatchHandle {
public:
struct BufferBase {
char* const bytes;
Best regards.
--
Manuel.
