C++ build options

["Cliff Jansen (Interop Systems Inc)" <v-...@microsoft.com>]

In "Re: C++ Trunk - Code generator does not generate
generate_MaxMethodBodySize_h.cpp file", Alan Conway wrote:

> I've been tempted for a while to move the build system to cmake -
> there's a good writeup from the KDE project. Anyone know enough about
> cmake to say if this would reduce or increase the amount of
> per-platform stuff in the build system between Unix & windows?

I also would welcome any experience that can be shared regarding cmake
or similar tools.  On the face of it, KDE is sufficiently complex that
cmake (and ctest) should be able to accommodate the Qpid C++
implementation.  The main gotcha is most likely to be handling the
auto generated code.

Cmake has obvious advantages for many Windows developers since they
wouldn't have to learn a foreign shell environment and they'd get the
IDE project files that they usually expect.

So if there is a desire to switch to a cross-platform build tool, I
am certainly eager to help out.

On the other hand, it's worth noting that it is not particularly
difficult to take the M4 distribution (i.e. post-bootstrap) and to
build the broker in cygwin using "configure; make".  Some
posix/foo.cpp files need to be replaced with windows/bar.cpp
equivalents and some of the link lines need tweaking - all to be
expected.  There also appears to be a large build-time penalty in
libtool, but I suspect that can be addressed.

An alternative for M5 could be to update the autotools bootstrap
mechanism to work in (one, or all of) msys/cygwin/SUA with Visual C++
(something like the Mozilla folks do).  To clarify: I am talking about
the build environment for Qpid developers as opposed to users building
applications that use Qpid. I am not suggesting that an average
Windows developer should need to install a special msys environment to
build or use M5.

Also even if we adopt the autotools as the primary build mechanism on
Windows, that doesn't preclude a secondary mechanism for use by
Windows developers who wish to use Visual Studio for their work.  I
would envision that each release would continue to provide working
project and solution files for an easy point and click build.  They
would just be updated less often or require some script/tool in an
intermediate step.  However, each stable "Mx" release would include
an easy to use IDE build and development environment.

If there is insufficient interest in a going the cross-platform route,
such as cmake, I am willing to work on these autotools related changes
for M5 to sync the Linux and Windows build.

Cliff

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

RE: C++ build options

[Steve Huston <sh...@riverace.com>]

Picking up from end of January...
> -----Original Message-----
> From: Cliff Jansen (Interop Systems Inc) 
> [mailto:v-cljans@microsoft.com] 
> Sent: Thursday, January 29, 2009 6:48 PM
>
> Alan Conway wrote: 
> > I'd be interested in cmake only if it gives us significantly
> > smaller/simpler build files that are easier to maintain. The KDE
> > writeup suggested that might be the case but someone would 
> really have
> > to try it to know.
> [...]
> > I'd really like to give cmake a chance before we extend autotool's
> > reign of terror.
> >
> > Would you consider trying to hack up a cmake build, at 
> least enough to
> > get a feel for the size of the task?
> 
> I will gladly do so and report back ASAP.

I'm also planning to work further in this area (I've talked with
Cliff) and am eager to know if anyone has any further up/down opinion
of Cmake, since that's the likely first option to work on.

-Steve


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

RE: C++ build options

["Cliff Jansen (Interop Systems Inc)" <v-...@microsoft.com>]

Alan Conway wrote: 
> I'd be interested in cmake only if it gives us significantly
> smaller/simpler build files that are easier to maintain. The KDE
> writeup suggested that might be the case but someone would really have
> to try it to know.
[...]
> I'd really like to give cmake a chance before we extend autotool's
> reign of terror.
>
> Would you consider trying to hack up a cmake build, at least enough to
> get a feel for the size of the task?

I will gladly do so and report back ASAP.

Cliff


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

Re: C++ build options

[Alan Conway <ac...@redhat.com>]

Cliff Jansen (Interop Systems Inc) wrote:
> In "Re: C++ Trunk - Code generator does not generate
> generate_MaxMethodBodySize_h.cpp file", Alan Conway wrote:
> 
>> I've been tempted for a while to move the build system to cmake -
>> there's a good writeup from the KDE project. Anyone know enough about
>> cmake to say if this would reduce or increase the amount of
>> per-platform stuff in the build system between Unix & windows?
> 
> I also would welcome any experience that can be shared regarding cmake
> or similar tools.  On the face of it, KDE is sufficiently complex that
> cmake (and ctest) should be able to accommodate the Qpid C++
> implementation.  The main gotcha is most likely to be handling the
> auto generated code.
> 
> Cmake has obvious advantages for many Windows developers since they
> wouldn't have to learn a foreign shell environment and they'd get the
> IDE project files that they usually expect.
> 
> So if there is a desire to switch to a cross-platform build tool, I
> am certainly eager to help out.
> 
> On the other hand, it's worth noting that it is not particularly
> difficult to take the M4 distribution (i.e. post-bootstrap) and to
> build the broker in cygwin using "configure; make".  

My beef with autotools is not the end user experience, which as you say is
quite simple, but the developer experience. Libtool's fake-exe wrapper scripts
are a constant source of annoyance and I feel that making changes to
the configure.ac file is more complex than need be.

I'd be interested in cmake only if it gives us significantly smaller/simpler
build files that are easier to maintain. The KDE writeup suggested 
that might be the case but someone would really have to try it to know.

> An alternative for M5 could be to update the autotools bootstrap
> mechanism to work in (one, or all of) msys/cygwin/SUA with Visual C++
> (something like the Mozilla folks do).  To clarify: I am talking about
> the build environment for Qpid developers as opposed to users building
> applications that use Qpid. I am not suggesting that an average
> Windows developer should need to install a special msys environment to
> build or use M5.
> 
> Also even if we adopt the autotools as the primary build mechanism on
> Windows, that doesn't preclude a secondary mechanism for use by
> Windows developers who wish to use Visual Studio for their work.  I
> would envision that each release would continue to provide working
> project and solution files for an easy point and click build.  They
> would just be updated less often or require some script/tool in an
> intermediate step.  However, each stable "Mx" release would include
> an easy to use IDE build and development environment.
> 
> If there is insufficient interest in a going the cross-platform route,
> such as cmake, I am willing to work on these autotools related changes
> for M5 to sync the Linux and Windows build.

That sounds sensible if we don't go to cmake or some other 
tool that simplifies both. However I've been steeped in sh and 
make for years and *I* hate autotools, so I'm not sure how it would
feel to windows developers. I'd really like to give cmake a chance 
before we extend autotool's reign of terror.

Would you consider trying to hack up a cmake build, at least enough 
to get a feel for the size of the task? 

Cheers,
Alan.

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org