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

[Marek Brudka]

Hi,
User J.T. Conklin wrote:

>Marek Brudka <mbrudka@aster.pl> writes:
>  
>
>>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.
>>    
>>
>
>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.

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.

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

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

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

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

Marek