[Pkg-ace-devel] Re: Bug #1854 RESOLVED/FIXED: Reactor separation

[Marek Brudka]

U=BFytkownik Raphael Bossek napisa=B3:

>Hi Marek,
>
> =20
>
>>My plan regarding Raphael patch is to first make it working under
>>linux (debian sarge),
>>   =20
>>
>I can satisfy you that it works already. Thomas Girard and I get it
>running. We maintain the Debian version of ACE+TAO+CIAO in our own
>CVS repo because of additional modifications and addons for Debian.
>We have had to solve some of MPC problems while creating GNUmakefiles.
>But this is not a problem of the patch I applied for bug 1854.
>
>If you need more information please contact pkg-ace-devel@lists.alioth.d=
ebian.org
>the official mailing list for ACE+TAO+CIAO Debian maintainers.
> =20
>
I'm sure it works under Debian as I applied it rather easily. The=20
problem is not if the patch is
working, but the way it works. In general, there are too many additional=20
unnecessary constructs
that makes using specific reactor hard for an average developer. I do=20
not want to go into
details now, I'd better change ACE in REACTOR_SEPARATION branch, and=20
after that I'll be
ready to discuss proposed solutions. Please supervise my work if you=20
wish to, as in configuration
management it is very easy to make a mistake.

>>To generate makefiles for qtreactor one has to either set "qt=3D1" in=20
>>global features or pass "-features qt=3D1" to mwc.pl.
>>   =20
>>
>For the Debian packages (with reactor seperation applied) we use a
>MPC feature file (debian/config/debian.features). MPC will be called
>to generate the GNUmakefiles using this feature file. This file will als=
o
>be converted to a ACE_wrappers/include/makeinclude/platform_linux.GNU by
>repacing // comments to # comments for GNU make. Nothing else have to be
>done to get the features compiled. More details in debian/rules.
>
>The CVS repo can be found at http://einstein.speech-design.de/webtools/c=
vs/debian/package/ace/
>
> =20
>
>>Generated makefiles has everything needed to compile and link against Q=
t,
>>particullary -DACE_HAS_QT=3D1 is set up, but each time make is called
>>one has to pass qt=3D1.
>>   =20
>>
>Not for us where MPC generated the GNUmakefiles based on the feature
>file debian/config/debian.features.
> =20
>
Do you really does not have to invoke "make qt=3D1" for building ACE? The=
n=20
I suppose you patch few files
from "include/makeinclude "while building debian package (IMHO debian=20
package is one of the bests for ACE).
Here are my results for ACE your patch was applied=20
($ACE_ROOT/bin/MakeProjectCreater/config/global.features
has qt=3D1):

marek@cindirella:/opt/public/ACE_wrappers/ace$ mwc.pl ace.mwc
MPC_ROOT was set to /opt/public/MPC/.
Generating gnuace output using ace.mwc
Start Time: Sun Dec  5 20:59:28 2004
Skipping QoS (qos.mpc), it requires qos.
Skipping SSL (ssl.mpc), it requires ssl.
  End Time: Sun Dec  5 20:59:33 2004

The invoking make leads to:

marek@cindirella:/opt/public/ACE_wrappers/ace$ make
...(skipped)..
make[1]: Leaving directory `/opt/public/ACE_wrappers/ace'
make[1]: Entering directory `/opt/public/ACE_wrappers/ace'
This project will not be built due to one of the following missing featur=
es:
qt

GNUmakefile: /opt/public/ACE_wrappers/ace/GNUmakefile.ACE_QtReactor=20
MAKEFLAGS=3Dw
...(skipped)..

After invoking make qt=3D1, one gets

marek@cindirella:/opt/public/ACE_wrappers/ace$ make qt=3D1
make[1]: Entering directory `/opt/public/ACE_wrappers/ace'
...(skipped)...
GNUmakefile: /opt/public/ACE_wrappers/ace/GNUmakefile.ACE_QtReactor=20
MAKEFLAGS=3Dw -- qt=3D1
...(skipped)...
rm -f libACE_QtReactor.so
ln -s libACE_QtReactor.so.5.4.2 libACE_QtReactor.so
chmod a+rx libACE_QtReactor.so.5.4.2
...(skipped)...

The additional qt=3D1 option passed to make (not MPC!) is not necessary.=20
Moreover, under MSVC after generation
of vcproj's one does not have to set any additional option, invoking=20
"Build Solution" is just enough to build ACE and
ACE_QtReactor. When one considers building ACE distribution only, then=20
additional qt=3D1 when invoking make does not
matter, but when one has to develope under linux an application using=20
ACE and Qt, then "qt=3D1" is irritating because it
does not introduce any additional value (BTW. I know scripts and aliases=20
;-) ).

>>ACE is now heavily dependant on MPC, then why not to remove this option
>>from platform_macros?
>>   =20
>>
>I think you are talking about ACE_wrappers/include/makeinclude/wrapper_m=
acros.GNU,
>do you? I can convirm that ACE is a huge and complex pice of software
>
:-)))

>but I do not think that the concept of features is that worse.=20
>
 Neither do I. But there is a difference between MPC features (those set=20
in *.features files) and make features
(variants) set in make's command line. In general, while the former=20
really simplifies configuration management,
the latter exists mainly for building variants (in boost::bjam sense)=20
like debug/inline/optimize.

>Either I do not see an alternative that will legitimate a change.
> =20
>
Well, I and my mates use ACE everyday under three OS. And we all agree,=20
that using (building) ACE should be
"as simple as possible, but not more than that" :-). Passing options,=20
deriving from additional magic base projects, defining all
those ACE_HAS_QT , in general "rain dancing" to make things compiling=20
and linking is at least incovienent. Moreover,
some other ace-users have problems with compiling ACE for Qt (see=20
archive). I'd like to change this, and please see preliminary
ACE-INSTALL.html in REACTOR_SEPARATION branch=20
(http://cvs.doc.wustl.edu/viewcvs.cgi/*checkout*//ACE-INSTALL.html?rev=3D=
4.345.2.1&only_with_tag=3DREACTOR_SEPARATION#qtreactor_install)
 to get a rough idea how.

>>There are more options like this one, and I think they only complicate
>>ACE subsetting.
>>   =20
>>
>It's not easy but it's not impossible.
> =20
>
I agree. Moreover, it would be better to have ACE already subset in cvs,=20
rather than to play with its configuration files
individually.

Concluding my long letter, from a configuration perspective ACE "GUI"=20
reactors  should be managed almost the same
way ACE_SSL is with some additional improvements.

Marek Brudka