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

J.T. Conklin jtc@acorntoolworks.com
Tue, 25 Jan 2005 00:31:26 -0800


Hi Marek,

>>It's not clear to me that ACE_??Reactor and TAO_??Resource libraries
>>are distinct packages.  They are just libraries that are selectively
>>enabled when ACE/TAO are configured (like ACE_SSL, ACE_QoS, ....).
>>And in my opinion, there only should be one knob to configure them
>>(again like ACE_SSL, ACE_QoS, ...).
>>
>>
> There are application and operating systems (eg. Neutrino, and
> several in my company), where only ACE is used, but not TAO. There
> are also applications and platforms, where only ACE is employed but
> without ACE_QtReactor. If everything comes with one huge library
> then users of ACE have many problems with configuring, developing
> and distributing their products.

Ok, but I'm not advocating going back to a single monolithic library.

> I use ACE for some time and know it too well. Exemplary problem: for
> even a medium size company a binary distribution of ACE has to be
> prepared because most of developers should not compile ACE by
> themself, because they would lost to much time as well as they
> usually do not know how do it well. If ACE is one big package, then
> the configuration manager has to prepare all the variants of ACE
> being used in company eg.  raw ACE, ACE+QtReactor, ACE+TAO, ACE and
> all the combination one can imagine. The number of distribution
> without a reasonable splitting grow as n^2, where n is number of
> subpackages. In fact there are also many problems with all those
> configuration options inside config.h, when one consider deployment
> packages for developers.

I'm resposible for the binary ACE and TAO packages used at my company.
I configure, build, and install a single set of libraries.  It's true
that this wouldn't have been possible if we were using a GUI reactor,
but now that they've been split into separate libraries I'll be able
to install all of them at once as well.  It doesn't matter that some
of our service objects only use ACE while others use ACE and TAO, as
those can pick and choose what libraries to link with.

1 set of MPC options -> 1 set of autoconf/configure options -> one set
of ACE/TAO libraries.

>> So the expectation is that projects that use ACE/TAO would also use
>> a installed version of MPC for their make/project files?  Is this
>> done today?  Is it considered desirable?  Why was this done for the
>> reactors and not ACE_SSL, ACE_QoS, ACE_RMCast, ACE_TMCast, etc?
>>
> One cannot make such assumption. But one should enable to do it,
> because MPC faciliates developement.

If you say so.  It's not my call, but this seems outside of the DOC
groups mandate to provide this, so it may be up to third parties to
productize and maintain an "installed" MPC with a compatible set of
configuration files that match the installed ACE and TAO libraries.
If this is the case, it is reasonable for the DOC groups MPC config
to have a single knob that if set causes each GUI reactor and its
cooresponding TAO resource to be built.

>>Just so you know where I'm coming from, I find it presumptuous to the
>>point of being rude when an operating system or development framework
>>expects me to adapt to it's build infrastructure for my applications
>>rather than the other way round.  The new pkg-config *.pc files allow
>>users to select libraries (and even detect their existance) in a much
>>more build-tool independent way.
>>
> Configuration management is an important, though often
> underestimated phase of software developement. It has an impact on
> not only the implementation but even the design and analysis. Each
> OO methodology eg. RUP and Quality Assurance eg. ISO 9001 or CMM
> starting from level 3 tell that.

Agreed, but it is *me* not some library or operating system that
should be in charge of my configuration management architecture.  You
seemed to be promoting MPC as a or perhaps the only first class build
tool, which is what raised my concern.

>>I believe multiple MPC options to select whether a library is built
>>and whether it is installed puts a huge burden on the DOC group's
>>build infrastructure for limited benefit.
>
> I use such means for some time not only in ACE but also in a number
> of company projects. From user point of view these burden are only
> few additional options to MPC, which can easily be manage by higher
> level script.  But one gains this a way a complete control over
> built process which leads to better program. It's funny, but I
> obsererved that half of the problems developers have in their
> everyday practice is related with bad build (especially under
> windows) eg. incompatible libraries linked togather. Build process
> should make it easier to avoid them.

See my earlier message.  It adds hundreds of extra build combinations
that need to be tested.  Without someone committing machine cycles so
that they're covered by the scoreboard, these (IMO unnecessary)
options will tend to reduce, not increase, ACE/TAO quality.

>>If subsets of ACE and TAO are being packaged and distributed by third
>>parties, I think the onus should be on them to deal with any unique
>>packaging issues created by that partitioning.
>>
>>
> It was possible for ACE, but not for TAO. TAO and GUIResources were
> seriously redesigned to enable such separation. And the patches and
> script for making this were longer and longer, but I think debian
> developers can tell us more about it.

Again, you seem to be arguing that I'm against the reactor separation.
I'm not.  I'm only objecting to the way it's enabled/configured in MPC.

    --jtc

-- 
J.T. Conklin