[ace-users] autotools
Pau Garcia i Quiles
What's the status of the autotools build system in ACE? Does it really
work? I've used mwc.pl to generate the configure stuff but the
generated 'configure' does not work (it's malformed). Actually, it has
never worked for me without manual patching :-/
I'm asking because every time someone comes to the list with a problem
with autotools, the answer he's given is to use the 'traditional'
build system (i. e. no real solution to the autotools issue)
Also, have you thought of moving from MPC to a more extended build
system, which works on all platforms (for instance, CMake) ?
Thanks.
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
Douglas C. Schmidt
Hi Pau,
> What's the status of the autotools build system in ACE? Does it really
> work?
No, not really.
> I've used mwc.pl to generate the configure stuff but the generated
> 'configure' does not work (it's malformed). Actually, it has never
> worked for me without manual patching :-/
>
> I'm asking because every time someone comes to the list with a problem
> with autotools, the answer he's given is to use the 'traditional'
> build system (i. e. no real solution to the autotools issue)
The 'traditional' system works well, so we recommend people use it. If
someone wants to take the time to get the autotools build system working
again, however, that would be great.
> Also, have you thought of moving from MPC to a more extended build
> system, which works on all platforms (for instance, CMake) ?
Can you please let us know what platforms MPC doesn't work on? We've used
it successfully for the many platforms that ACE+TAO run on and it seems
to work well.
Thanks,
Doug
> Thanks.
>
> --
> Pau Garcia i Quiles
> http://www.elpauer.org
> (Due to my workload, I may need 10 days to answer)
> _______________________________________________
> ace-users mailing list
> ace-...@list.isis.vanderbilt.edu
> http://list.isis.vanderbilt.edu/mailman/listinfo/ace-users
Steve Huston
> What's the status of the autotools build system in ACE? Does it
really
> work?
It does work, but the set of feature tests doesn't always detect the
same results as a hand-built config in the traditional build. It could
use some improvements.
> I've used mwc.pl to generate the configure stuff but the
> generated 'configure' does not work (it's malformed). Actually, it
has
> never worked for me without manual patching :-/
This has always been the case... That's why the Makefile.am files are
checked into the repo, not generated from MPC. You should not need to
regenerate them unless you change the set of files.
> I'm asking because every time someone comes to the list with a
problem
> with autotools, the answer he's given is to use the 'traditional'
> build system (i. e. no real solution to the autotools issue)
That's mostly because the traditional build tends to work better since
it's tested across more platforms. It's hard to get someone to spend
free time working an issue that can be worked around by changing the
build scheme.
> Also, have you thought of moving from MPC to a more extended build
> system, which works on all platforms (for instance, CMake) ?
MPC generates more varied platform projects than CMake does. I use
CMake on another project (Apache Qpid). It has some really nice
features, but a more varied set of supported platforms is not one of
them.
Best regards,
-Steve
--
Steve Huston, Riverace Corporation
Total Lifecycle Support for Your Networked Applications
http://www.riverace.com
Pau Garcia i Quiles
> Hi Pau,
>
>> What's the status of the autotools build system in ACE? Does it
> really
>> work?
>
> It does work, but the set of feature tests doesn't always detect the
> same results as a hand-built config in the traditional build. It could
> use some improvements.
>
>> I've used mwc.pl to generate the configure stuff but the
>> generated 'configure' does not work (it's malformed). Actually, it
> has
>> never worked for me without manual patching :-/
>
> This has always been the case... That's why the Makefile.am files are
> checked into the repo, not generated from MPC. You should not need to
> regenerate them unless you change the set of files.
In particular, I'm having trouble when packaging ACE for Debian.
Debian mandates that generated files not be packaged but regenerated,
exactly to prevent situations like the one ACE is suffering: the build
system is broken and you need to manually edit the generated
(Makefile.am, etc) files, in non-obvious places, in non-obvious ways.
>> I'm asking because every time someone comes to the list with a
> problem
>> with autotools, the answer he's given is to use the 'traditional'
>> build system (i. e. no real solution to the autotools issue)
>
> That's mostly because the traditional build tends to work better since
> it's tested across more platforms. It's hard to get someone to spend
> free time working an issue that can be worked around by changing the
> build scheme.
Problem with the traditional build system is it requires more manual
steps (paths to Qt, Tcl/Tk, etc if you don't have them in the standard
locations) and you have to do that by editing .h files, adding new
stuff (which you may know or may not know it exists) and you better
make sure you add it in the right place or it does not take effect or
even breaks the build :-/
>> Also, have you thought of moving from MPC to a more extended build
>> system, which works on all platforms (for instance, CMake) ?
>
> MPC generates more varied platform projects than CMake does. I use
> CMake on another project (Apache Qpid). It has some really nice
> features, but a more varied set of supported platforms is not one of
> them.
What are those platforms? CMake supports a lot of platforms and CMake
2.6 (released in July 2008) improved support for cross-compiling.
NB: I'm willing to spend my time "porting" ACE to CMake so that we
have the same build-system on every platform and it works on every
platform, in an easy way, but only if I know it would be accepted
upstream and it would become *the* first citizen in buildsystems.
Pau Garcia i Quiles
<sch...@dre.vanderbilt.edu> wrote:
> The 'traditional' system works well, so we recommend people use it. If
> someone wants to take the time to get the autotools build system working
> again, however, that would be great.
That will not be me. I avoid autotools like the plague :-)
>> Also, have you thought of moving from MPC to a more extended build
>> system, which works on all platforms (for instance, CMake) ?
>
> Can you please let us know what platforms MPC doesn't work on? We've used
> it successfully for the many platforms that ACE+TAO run on and it seems
> to work well.
It does not work on Debian Unstable, for instance ("Debian" meaning
"any Debian-derivative, including Ubuntu"). The generated 'configure'
does not work. I'm trying to bring ACE 5.7.4 to Debian using the ACE
5.6.3 packaging as the starting point. The generated 'configure' file
does not work.
Download http://download.dre.vanderbilt.edu/previous_versions/ACE+TAO+CIAO-src-5.7.4.tar.bz2,
install Tcl/Tk, Qt, zlib, FLTK, OpenSSL, etc and try this on Debian
Unstable:
$ mkdir objdir
$ export ACE_ROOT=`pwd`/ACE_wrappers
$ export TAO_ROOT=$ACE_ROOT/TAO
$ export CIAO_ROOT=$TAO_ROOT/CIAO
$ export DANCE_ROOT=$CIAO_ROOT/DAnCE
$ export DDS_ROOT=$CIAO_ROOT/connectors/dds4ccm
$ cd ACE_wrappers
$ ./bin/mwc.pl -noreldefs -type automake -features
"ssl=1,zlib=1,zzip=1,xt=1,tk=1,fl=1,qt=1,fox=1" -noreldefs ACE.mwc
$ cd TAO
$ ../bin/mwc.pl -noreldefs -type automake -features
"ssl=1,zlib=1,zzip=1,xt=1,tk=1,fl=1,qt=1,fox=1" -noreldefs TAO.mwc
$ cd ..
The next step fails already. It requires that you apply patches 93,
94, 95 and 96 from
http://svn.debian.org/viewsvn/pkg-ace/trunk/debian/patches/ (tested on
Mac OS X 10.6.2 and Debian Unstable):
$ ./bin/bootstrap
$ cd ../objdir
$ chmod +x ../ACE_wrappers/configure ../ACE_wrappers/TAO/configure
$ ../ACE_wrappers/configure --build i486-linux-gnu --prefix=/usr
--disable-tao-examples --disable-tao-tests --disable-ace-examples
--disable-ace-tests --enable-fl-reactor --enable-qt-reactor
--enable-xt-reactor --enable-tk-reactor --with-fox-config=/usr/bin
--enable-fox-reactor --with-tclconfig=/usr/lib
--with-tkconfig=/usr/lib --with-zlib --with-zzip --enable-ipv6
--enable-ipv4-ipv6 --enable-inline --enable-pthreads
--enable-symbol-visibility --enable-ace-reactor-notification-queue
That 'configure' fails due to a malformed if-then-else. I have not
found a solution for that yet.
We will probably move the Debian packaging to the traditional build
system but it's not like I love that "solution", either (it requires
that I dump all the work that's already there, for starters).
Pau Garcia i Quiles
<wo...@dre.vanderbilt.edu> wrote:
> Hi -
> On Nov 14, 2009, at 12:43 PM, Pau Garcia i Quiles wrote:
>
> In particular, I'm having trouble when packaging ACE for Debian.
>
> Debian mandates that generated files not be packaged but regenerated,
> exactly to prevent situations like the one ACE is suffering: the build
> system is broken and you need to manually edit the generated
> (Makefile.am, etc) files, in non-obvious places, in non-obvious ways.
>
>
> has already taken the effort to create debian packaging scripts.
The stuff in that directory is outdated and incoherent (it refers to
several different versions of ACE).
Take a look at http://svn.debian.org/viewsvn/pkg-ace/trunk/ (or
checkout svn://svn.debian.org/pkg-ace/trunk ) for something in better
shape.
> Problem with the traditional build system is it requires more manual
> steps (paths to Qt, Tcl/Tk, etc if you don't have them in the standard
> locations) and you have to do that by editing .h files, adding new
> stuff (which you may know or may not know it exists) and you better
> make sure you add it in the right place or it does not take effect or
> even breaks the build :-/
>
>
> That's a sign that you are likely using the traditional method of
> compilation incorrectly. Paths to external dependencies are almost always
> dependent on environment variables that must be set correctly - the only
> files you should be editing at all are config.h and platform_macros.GNU.
> Check out MPC/config/qt.mpb for an example.
> The traditional method of compilation is exercised on many dozens of
> different platform combinations every day, with wildly different features
> and filesystem layouts.
I'm not saying it does not work for different featuresets or
filesystem layouts. I'm sure it does. But it requires non-obvious
manual work. If the 'defaults' are OK for you, you barely need to
edit/add anything. If they are not (the case for the Debian
packaging), it requires some magic. It's only I'd like to have a
buildsystem which automagically works.
> NB: I'm willing to spend my time "porting" ACE to CMake so that we
> have the same build-system on every platform and it works on every
> platform, in an easy way, but only if I know it would be accepted
> upstream and it would become *the* first citizen in buildsystems.
>
> I doubt that is likely, as the scale of the project you propose is immense,
> as we depend on MPC to also build TAO, CIAO, and many other projects. In
> order for something other than MPC to be seriously considered as the primary
> build system for ACE, it would also have to be ported to TAO and CIAO as
> well.
Of course, when I say "ACE" I mean the whole guacamole (ACE, TAO,
CIAO, whatever). But before I endeavour in such an effort, I'd like to
know it's not going to be a waste of time.
> In addition to that, all of the various build sponsors would have to
> take time to install CMake on their systems.
That should not be an issue. ACE already has a good set of third-party
dependencies if you want to build all the various reactors (Qt, Xt,
Fox, FLTK, OpenSSL, zlib, lzo, etc). CMake has no 3rd party
dependencies at all, therefore it's just one more dependency
(actually, less than that, because you'd get rid of autotools)
Steve Huston
> In particular, I'm having trouble when packaging ACE for Debian.
>
> Debian mandates that generated files not be packaged but
regenerated,
> exactly to prevent situations like the one ACE is suffering: the
build
> system is broken and you need to manually edit the generated
> (Makefile.am, etc) files, in non-obvious places, in non-obvious
ways.
Ok... It may be more time-efficient to help improve MPC's automake
generation than to embark on a whole new packaging scheme.
> >> Also, have you thought of moving from MPC to a more extended
build
> >> system, which works on all platforms (for instance, CMake) ?
> >
> > MPC generates more varied platform projects than CMake does. I use
> > CMake on another project (Apache Qpid). It has some really nice
> > features, but a more varied set of supported platforms is not one
of
> > them.
>
> What are those platforms? CMake supports a lot of platforms and
CMake
> 2.6 (released in July 2008) improved support for cross-compiling.
The usual trouble-makers ;-) are VxWorks, QNX, ETS, etc.
> NB: I'm willing to spend my time "porting" ACE to CMake so that we
> have the same build-system on every platform and it works on every
> platform, in an easy way, but only if I know it would be accepted
> upstream and it would become *the* first citizen in buildsystems.
Since I remember the MPC transition being a huge effort with many
people involved for quite some time, I imagine it would be of the same
scale with Cmake. You will need a big budget and a compelling set of
reasons to make progress.
Pau Garcia i Quiles
I guess you are right but I don't know MPC and we still have the very
same problem: MPC is not extended, therefore bugs in the MPC stuff are
only fixable by a handful of people.
>> >> Also, have you thought of moving from MPC to a more extended
> build
>> >> system, which works on all platforms (for instance, CMake) ?
>> >
>> > MPC generates more varied platform projects than CMake does. I use
>> > CMake on another project (Apache Qpid). It has some really nice
>> > features, but a more varied set of supported platforms is not one
> of
>> > them.
>>
>> What are those platforms? CMake supports a lot of platforms and
> CMake
>> 2.6 (released in July 2008) improved support for cross-compiling.
>
> The usual trouble-makers ;-) are VxWorks, QNX, ETS, etc.
I know for certain VxWorks and QNX work fine with CMake. I don't even
know ETS (is that the Win32-like embedded OS? is it possible to get an
SDK for that without paying an arm and a leg?).
>> NB: I'm willing to spend my time "porting" ACE to CMake so that we
>> have the same build-system on every platform and it works on every
>> platform, in an easy way, but only if I know it would be accepted
>> upstream and it would become *the* first citizen in buildsystems.
>
> Since I remember the MPC transition being a huge effort with many
> people involved for quite some time, I imagine it would be of the same
> scale with Cmake. You will need a big budget and a compelling set of
> reasons to make progress.
I've moved many projects (open and closed source) to CMake, some of
them large. Granted, ACE+TAO+CIAO is huge but I think it should not be
that difficult or require that long (I'm not saying it would be a
weekend task, of course :-)
Chris Cleeland
On Nov 14, 2009, at 6:49 PM, Pau Garcia i Quiles wrote:
> MPC is not extended, therefore bugs in the MPC stuff are
> only fixable by a handful of people.
What do you mean when you say that "MPC is not extended"?
---
Chris Cleeland, Principal Software Engineer
http://www.theaceorb.com AND http://www.ociweb.com
Johnny Willemsen
> > You might take a look at ACE_ROOT/debianbuild, I believe Johnny
> Willemsen
> > has already taken the effort to create debian packaging scripts.
>
> The stuff in that directory is outdated and incoherent (it refers to
> several different versions of ACE).
>
> Take a look at http://svn.debian.org/viewsvn/pkg-ace/trunk/ (or
> checkout svn://svn.debian.org/pkg-ace/trunk ) for something in better
> shape.
As I indicated before, the files in debianbuild should be updated. It is not
a good thing to place these files outside ACE, they should be in the
distribution.
Johnny
Johnny Willemsen
Just not use autoconf as way to build a packaged tree. Use the
config.h/platform_macros.GNU approach to compile ACE. Than supply patches
for the debianbuild back to the mailing list so that things can be
integrated into ACE. That is the only way how things can be maintained,
putting packaging files outside of the core distribution is a maintenance
nightmare.
Johnny
> > The 'traditional' system works well, so we recommend people use it.
> If
> > someone wants to take the time to get the autotools build system
> working
> > again, however, that would be great.
>
> That will not be me. I avoid autotools like the plague :-)
>
> >> Also, have you thought of moving from MPC to a more extended build
> >> system, which works on all platforms (for instance, CMake) ?
> >
> --
> Pau Garcia i Quiles
> http://www.elpauer.org
> (Due to my workload, I may need 10 days to answer)
Thomas Girard
Johnny Willemsen wrote:
> Just not use autoconf as way to build a packaged tree. Use the
> config.h/platform_macros.GNU approach to compile ACE. Than supply patches
> for the debianbuild back to the mailing list so that things can be
> integrated into ACE. That is the only way how things can be maintained,
> putting packaging files outside of the core distribution is a maintenance
> nightmare.
Here's my point of view:
* it's easier to track packaging outside of the trunk, and synch
packaging when needed. Debian and ACE+TAO have different contraints
and schedule. It's harder to track a moving target rather than a
chosen one. Dependencies are evolving as well (g++, QT, autotools),
so focusing on the trunk version of ACE+TAO is something that
requires a lot of spare time.
Pease remember that once a version is available through Debian stable
it has to be supported by the Debian maintainer.
Anyway, now that Pau has stepped in to help on the maintenance the
Debian packages will be updated from 5.6.3+1.6.3 to the latest
release.
* autoconf support will *not* be dropped from the packages. This effort
has already improved ACE+TAO autoconf support. Debian runs on many
different architectures and OS (GNU/kFreeBSD, GNU/Hurd); so having
autoconf working out of the box is something that will benefit
both Debian and ACE+TAO.
But we can prepare an alternative package build mechanism that will
rely on the traditional method, and have this mechanism be the
default package building mode for Linux platforms.
Pau wrote:
>> It does not work on Debian Unstable, for instance ("Debian" meaning
>> "any Debian-derivative, including Ubuntu"). The generated 'configure'
>> does not work. I'm trying to bring ACE 5.7.4 to Debian using the ACE
>> 5.6.3 packaging as the starting point. The generated 'configure' file
>> does not work.
(...)
I eventually found the culprits on the 5.6.3+1.6.3 version. Using the
latest autotools, we have two errors:
1. there's and 'else fi' generated in configure, and the shell can't
grok it when there's nothing in between. It seems easy to fix this.
2. there's an 'fidone' instead of 'fi done'. This can be, at least,
worked-around.
I think packages for 5.6.3+1.6.3, even if outdated, should compile again
on Debian/unstable with those fixes.
Regards,
Thomas
Johnny Willemsen
> * it's easier to track packaging outside of the trunk, and synch
> packaging when needed. Debian and ACE+TAO have different contraints
> and schedule. It's harder to track a moving target rather than a
> chosen one. Dependencies are evolving as well (g++, QT, autotools),
> so focusing on the trunk version of ACE+TAO is something that
> requires a lot of spare time.
We see with redhat/suse that the spec files keep working, each time we just
update the package on opensuse build service and it works. When real changes
to ace/tao/ciao are made we make sure we keep these files updated. We want
todo the same for debian, if the files are in the distribution and work, we
can update their version info each time easily. Than the likelyhood to make
changes after that is very low.
> * autoconf support will *not* be dropped from the packages. This
> effort
> has already improved ACE+TAO autoconf support. Debian runs on many
> different architectures and OS (GNU/kFreeBSD, GNU/Hurd); so having
> autoconf working out of the box is something that will benefit
> both Debian and ACE+TAO.
Be aware that the core developer group never uses autoconf and never tests
the outcome of it. The fact that ace compiles doesn't mean it runs.
Johnny
Pau Garcia i Quiles
> Hello,
>
> Johnny Willemsen wrote:
>>
>> Just not use autoconf as way to build a packaged tree. Use the
>> config.h/platform_macros.GNU approach to compile ACE. Than supply patches
>> for the debianbuild back to the mailing list so that things can be
>> integrated into ACE. That is the only way how things can be maintained,
>> putting packaging files outside of the core distribution is a maintenance
>> nightmare.
>
> Here's my point of view:
> packaging when needed. Debian and ACE+TAO have different contraints
> and schedule. It's harder to track a moving target rather than a
> chosen one. Dependencies are evolving as well (g++, QT, autotools),
> so focusing on the trunk version of ACE+TAO is something that
> requires a lot of spare time.
>
> it has to be supported by the Debian maintainer.
Fully agreed. In fact, I'd prefer if the 'debianbuild' contents would
be removed and it just contained a README.Debian telling people to go
to http://packages.debian.org/libace-dev for the source/binary
packages, and pkg-ace-devel if they want to help with packaging.
> Anyway, now that Pau has stepped in to help on the maintenance the
> Debian packages will be updated from 5.6.3+1.6.3 to the latest
> release.
>
> * autoconf support will *not* be dropped from the packages. This effort
> has already improved ACE+TAO autoconf support. Debian runs on many
> different architectures and OS (GNU/kFreeBSD, GNU/Hurd); so having
> autoconf working out of the box is something that will benefit
> both Debian and ACE+TAO.
>
> But we can prepare an alternative package build mechanism that will
> rely on the traditional method, and have this mechanism be the
> default package building mode for Linux platforms.
>
> Pau wrote:
>>>
>>> It does not work on Debian Unstable, for instance ("Debian" meaning
>>> "any Debian-derivative, including Ubuntu"). The generated 'configure'
>>> does not work. I'm trying to bring ACE 5.7.4 to Debian using the ACE
>>> 5.6.3 packaging as the starting point. The generated 'configure' file
>>> does not work.
>
> (...)
>
> I eventually found the culprits on the 5.6.3+1.6.3 version. Using the latest
> autotools, we have two errors:
> 1. there's and 'else fi' generated in configure, and the shell can't
> grok it when there's nothing in between. It seems easy to fix this.
Yes, I had already located and worked this around.
> 2. there's an 'fidone' instead of 'fi done'. This can be, at least,
> worked-around.
Thanks! This was the main stopper I was suffering now. I had not
noticed the 'fidone's (there are several of them). I have now manually
fixed them and ACE 5.7.4 is building. This makes ACE 5.7.4 be "almost"
in Debian :-)
> I think packages for 5.6.3+1.6.3, even if outdated, should compile again
> on Debian/unstable with those fixes.
It'd require a few patches from pkg-ace/trunk/debian/patches still
(93-96 but I'm speaking from memory).
I'll have some news on the Debian packaging for 5.7.4 this Tuesday night.
Douglas C. Schmidt
Hi Pau,
We appreciate your help on this. Please let us know what fixes we
need to add to ACE+TAO to get them building on Debian more smoothly!
Thanks,
Doug
Johnny Willemsen
> > Pease remember that once a version is available through Debian
> stable
> > it has to be supported by the Debian maintainer.
>
> Fully agreed. In fact, I'd prefer if the 'debianbuild' contents would
> be removed and it just contained a README.Debian telling people to go
> to http://packages.debian.org/libace-dev for the source/binary
> packages, and pkg-ace-devel if they want to help with packaging.
We would like to keep it inside the package. Than we can use opensuse build
service to build for debian/ubuntu.
Johnny