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

[Marek Brudka]

U=BFytkownik Raphael Bossek napisa=B3:

>>I do not want to go into details now, I'd better change ACE in
>>REACTOR_SEPARATION branch, and after that I'll be ready to discuss
>>proposed solutions. Please supervise my work if you wish to, as
>>in configuration management it is very easy to make a mistake.
>>   =20
>>
>Ok, I will observe your modifications.
> =20
>
Thanks.

>>Do you really does not have to invoke "make qt=3D1" for building ACE?
>>   =20
>>
>No. Because we set all features again for include/makeinclude/platform_m=
acros.GNU
>by converting the feature file to a Makefile.
> =20
>
I see. I didn't know that.

>>Then I suppose you patch few files from "include/makeinclude "while
>>building debian package (IMHO debian package is one of the bests for AC=
E).
>>   =20
>>
>Modifing the platform_macros.GNU file is not a patch then a proposed way
>to configure ACE. We are doing this at build time by converting the MPC
>feature file in debian/rules (Debian's way to manufacture new packages).
>
>Maybe it's a patch for you.=20
>
It is, as usually I create a symlink to platform_linux.GNU. Certainly,=20
another option is to
include platform_linux.GNU in platform_macros.GNU. You right the second=20
option is not a
patch.

>From my point of view, MPC should do this job
>by itself depending on the output format of the Makefiles/projects.
> =20
>
Right. Probably, this is the next thing to be done.

>>The additional qt=3D1 option passed to make (not MPC!) is not necessary=
.
>>   =20
>>
>I think you should consider to convert the $ACE_ROOT/bin/MakeProjectCrea=
ter/config/global.features
>file the same way Debian is doing. Here is a simple and easy to understa=
nd
>Makefile rule used by Debian to convert their debian.feature file (a rep=
lacement
>for global.features):
>
>$(ACE_ROOT)/include/makeinclude/platform_macros.GNU:	$(ACE_ROOT)/debian.=
features
>	sed -e 's/^\/\//#/g' "$^" > "$@"
>	echo >> "$@"
>	echo "include \$$(ACE_ROOT)/include/makeinclude/platform_linux.GNU" >> =
"$@"
> =20
>
Cool, but it's only a patch. But as you mentioned few times a better way=20
is to improve MPC.

>Leting MPC apply the feature definitions to GNUmakfile (in sence of plat=
form_macros.GNU)
>would solve the difference, whould not? This applies only for the GNUmak=
efile
>target I think. Maybe there are more MPC targes have to be considered to=
o?
> =20
>
Unfortunatelly, I know only MSVC and gnuace targets.

>A advantage in subsetting some of the features would be a simple to
>build default ACE functionality. The disadvantage would be subsets not
>in sync with the MAIN branch. As consequence the release management
>and quality assurance are much more time consuming.
> =20
>
Sorry, I didn't get it. I hope to migrate the changes I'm working on to=20
MAIN branch after testing
and approval. Obviously, I'll not modify MPC as I do not want to get=20
lost in changes.

>For all those features today can be enabled/disabled by options I would
>not confirm to subseting ACE in subprojects. If I'm right a improved
>MPC version for ACE can solve the GNUmakefile definitions easily.
> =20
>
>Hmm, if I can remember you have to set ssl=3D1 while calling make (in
>the non-Debian way) the same way as make qt=3D1. ssl is a feature as qt =
is.
> =20
>
I thought more about ACE_HAS_SSL macro than make ssl=3D1. But once again=20
I'm for changing MPC
to include required features in GNUmakefiles.

Let me ask you few questions related to separation of reactors:

1. Do we really need ace(tao)_qtreactor mpc::features, namely requires=20
+=3D ace(tao)_qtreactor in ace(tao)_qtreactor.mpb?
Why not to assume that if Qt feature is set, then ACE is compiled with=20
Qt support? If ACE was not compiled with Qt support, but
qt=3D1 is set and user application derives from ace_qtreactor.mpb, then a=
t=20
the worst case linker will report an error. In other words cannot
we assume that qt=3D1 implies Qt support in ACE distribution? On the=20
contrary ace(tao)_qtreactor feature seems to be  consistant
with the rest of ACE. Moreover, I can imagine that someone sets qt=3D1 in=
=20
his configuration for enable MPC support for Qt. But as long  as
user application  does not derive from ace_qtreactor.mpb then=20

2. Do we need all those Qt related options  in=20
include/makeinclude/platform* ? Everything is already set by MPC, hence=20
these option seems
to be obsolete. Can we assume that user applications use=20
include/makeinclude/platform* files only vie MPC generated makefiles ?

3. Should ACE_QtReactor have their own folder in ACE_wrappers/ace, the=20
same way SSL has? For me it seems quite reasonable,
but this solution may confuse the actual ACE based applications as=20
QtReactor header would change its location.

TIA
Marek Brudka