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

[J.T. Conklin]

Hi Marek,

Marek Brudka <mbrudka@aster.pl> writes:
>>Nope. Promoting that is bad, though we have been doing it today, we
>>should be getting away from it as much as possible. If not, the DOC
>>repo changes to MPC and GNUmakefiles would start affecting
>>applications build environment, which is nasty. I know we have been
>>promoting that today, but if possible we should reduce those
>>dependancies.
>>
>> > Why was this done for the reactors and not ACE_SSL, ACE_QoS,
>> > ACE_RMCast, ACE_TMCast, etc?
>>
>>Right!
>>
> Great idea! I'm for it. In general it is better to create separate
> libraries than using preprocessor macros.
>
> BTW. ACE_RMCast and ACE_TMCast are separated libraries now.

I'm not objecting to the fact that the GUI Reactor implementations
have been split out into separate libraries.  I think it is a very
good thing (I've said that before in this thread).

What I am objecting to is the extra configuration knobs that added to
MPC.  With four reactors and four (sensible) MPC options per reactor,
there are now 256 possible configurations that need to be continuously
built and tested.  That is more configurations than are being built in
the scoreboard today!  Having one option per reactor type cuts us down
to 16 combinations, which is much more reasonable to test.

When I mentioned ACE_RMCast and ACE_TMCast, I knew that they were
separate libraries.  I was questioning why the reactor libraries
should have separate MPC options to control whether they built and
built and whether they are installed, when libraries like ACE_RMCast
and ACE_TMCast only have a single MPC option (actually, I learned
tonight that TMCast doesn't have an MPC at all; and Bala advocates
(and I concur) that the RMCast option should be removed).

    --jtc

-- 
J.T. Conklin