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

[Balachandran Natarajan]

Marek-

On Monday, 24 January, 2005 at 00:38:30 +0100, Marek Brudka 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. 

Right, the tests depends on these features. But it is probably not
right to add configuration options to configure ACE+TAO to build or
test one of the tests in the distributions. Sadly we don't have that
decoupling done yet. 

 > >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.

And probably the right number of them ;)

 > 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. 

Right, I agree. But we do plan to have a switch that will build the
ACE_XtReactor provided xt=1 in the features files. 

 > Consequently, ACE_XtReactor and TAO libraries installed do not
 > ensure that TAO_XtResource is installed. 

I see things a bit differently. I see that the basic requirement to
TAO's XtReactor library has been satisfied. Once the requirement is
satisfied they can be built and installed. Having finer level control
is okay, but it seems more of a pin with very very marginal
returns (atleast for TAO). Blowing up the configuration space with
many options seems to introduce a problem, especially for testing. 

 > 
 > 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.

Please see above. I again see a common minimum baseline from where we
can make some assumptions, i.e, xt=1 available means ACE_XtReactor
available and so all the applications that use the XTReactor can be
built and run. 

 > 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.

I agree this is a nice idea. Since these features are in a seperate
libratry, I am not sure whether the finer level control is necessary
here. It seems more like an overkill. 

 > 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.

IIRC, the global.features was not designed to do that. It was designed
to provide a common minimum baseline for configuring certain parts of
ACE+TAO. 

HTH

Thanks
Bala