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

[Marek Brudka]

Hi,
User J.T. Conklin wrote:

>Ok, but I'm not advocating going back to a single monolithic library.
>  
>
I'm sorry, I misunderstood you, my fault.

>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.
>  
>
Right :-). I suppose you know configuration problems better than me, 
hence my
explanations were not necessary.

I see one can mention at least two different perspective on the role of 
MPC.
a) ACE developement and package building,
b) Developing external applications using binary distribution of ACE.

In a) one can assume that all necessary tools are installed, and even if 
they are not then
it does not really matter, because ACE maintainer knows about 
dependencies and
related issues. The additional switches for MPC are redundant here and 
simplicity of
configuration is prefered. For example, Debian ACE source cannot be 
installed but
compiled if all those GUI developement packages are not set. That's why 
these switches
rather does not simplifies developement of these packages, though IMO 
the overhead isn't
too great.

In b) developer does not compile ACE, hence binary packages should be 
reasonably fine
grained to reduce the dependencies of external applications. This is why 
it is good to have ACE
subsetted. If developer does not use MPC, then all those switches can be 
ignored.
But this case is quite different if both ACE and MPC binary packages are 
used. I made an
assumption (maybe bad), that the current build system should faciliate 
using ACE and MPC.
There were at least three reasons:

1. ACE/TAO/CIAO is a big project, hence it's developement (with respect 
to GUI) should
be formal to some degree. First of all we have the dependency chain
core_ACE <-- core_TAO <-- core_CIAO and I tried to mirror this. 
Secondly, I considered
GUI tests, examples and similiar application as a small projects 
depending on ACE,
hence I tried to create a formal way to develop them.

2.  I tried to release the external configuration managers or 
distribution maintainers
of inventing their own ACE+MPC methodology ( :-) ) because quite 
reasonable solution can
be proposed already by ACE.

3.  Moreover, if external developers invent their our "philosophy" then 
I'm almost sure they
will not be compatible. As a result, ACE+MPC based application developed 
under Debian
would not compile under Fedora or MSVC, because feature/switches would 
be different for various
platforms.

I agree, that my consideration are little MPC-centric. That's not 
because I love or promote MPC so
much :-), in fact it has many deficiencies when compared to other build 
tools, but rather because
I tried to summarize my experience on employing MPC and ACE in external 
applications.

I realize now I mixed these two perspectives namely a) and b) trying to 
achieve a kind of compromise.
Maybe the result is directed  too much into b) direction, but as for b) 
the most important issue for me
was 1).

What can we do then? My first proposition is to leave the things as they 
are with x11 and gl
features removed. It is not so bad, because the implication are not so 
painfull. The second
proposition is to create two partially distinct sets of base projects, 
one for compiling ACE/TAO/CIAO
only, and one for using ACE/TAO/CIAO components in external 
applications. The latter is the
current state of mpb, while the former would be controlled by external 
features only eg. qt, xt, fl, tk.
The problem with this solution is its inconsistency with the latter, the 
additional base projects, and
partially parallel mpb hierarchy.

Your opinions?

BTW. I do not agree that hundreds of extra builds are needed for current 
setup, because of dependencies eg.
one cannot compile TAO_QtResource with ACE_QtResource, but when 
ACE_QtResource is tested one does not need
to do it again when building TAO_QtResource. In fact only one build is 
necessary, exactly
the same as currently as rich as possible. The same  problems are 
present for building the entire OS
(Debian, Fedora)  distributions, though they are several magnitudes 
worse than for ACE. If they were built by
testing each combination there would not be any distribution for the 
next eternity :-).

Thanks

Marek