[Pkg-ace-devel] Re: [devo-group] reactor separation & automake

Marek Brudka mbrudka@aster.pl
Mon, 24 Jan 2005 00:38:30 +0100


Hi,
User  J.T. Conklin wrote:

>>Adding so many mpb options is IMHO adding too much complexity. For
>>example, xt without X11, i.e, xt=1 and x11=0 doesn't make much sense for
>>me. Having to set motif=1 is too much, since the Xt reactor AFAIK
>>doesn't depend on motif calls. 
>>
Hmm, ace_xtreactor project does not depend on motif feature, but 
tests/XtMotifReactor_Test does
as well as tests/XtAthenaReactor_Test.

>The ones that bother me the most are the duplicate knobs for each
>reactor type:
>        ??
>        ace_??reactor
>        tao_??resource
>
>Right now, I set all three corresponding automake conditional from a
>single --enable-* switch.  It seems that we could reduce this to one
>in MPC as well.
>  
>
I think that autoconf level is a very good place to introduce such 
dependencies.

The raw dependencies level seems to be important for packaging, as 
ACE_??Reactor librabries and
TAO_??Resource are distinct packages. For example, the fact that X11 and 
Xt and ACE libraries are
installed does not imply that ACE_XtReactor is also installed. 
Consequently, ACE_XtReactor and TAO
libraries installed do not ensure that TAO_XtResource is installed.

In general:

ace_??reactor is not necessary to compile ACE_??Reactor library. It is 
enough to have all ?? libraries.
But the application using ACE_??Reactor library has to know if this 
library is avalaible, hence ace_??reactor
feature.

The same applies to tao_??resource. To compile TAO_??Resource we need 
only ?? libraries and ACE_??Reactor.
But to use TAO_??Resource we need to know if TAO_??Resource is 
avalaible, hence tao_??resource feature.

This discrimination is important for developement packages. One may 
expect that after the installation of
ACE_??Reactor developement package, not only the adequate libraries and 
headers will be installed, but also
a global.features will be modified in post install stage to reflect that 
new developement library is available for
MPC users. AFAIK current distributions eg. debian one, does not behave 
this way, but in the future it would
be very convenient.

>I think we still need one feature per reactor type so that MPC still
>still generate the conditional code in the GNUMakefile/Makefile.am's.
>It could be enabled by default in MPC, but would need the "xt=1" or
>"--enable-xt-reactor" to take effect.
>  
>
What about the additional keyword *ignores* for superseding features at 
MPC level I described
in previous post?

I suppose these issues were already discussed by Raphael Bossek on bug 
#1854.

Thanks

Marek