[Pkg-ace-devel] Re: Bug #1854 RESOLVED/FIXED: Reactor separation

[Raphael Bossek]

--Signature=_Sun__5_Dec_2004_23_30_11_+0100_Gn.M9.zxGr7zzALM
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Hi Marek,

> In general, there are too many additional unnecessary constructs
> that makes using specific reactor hard for an average developer.
I do not know the skills of a commmon ACE developer. I know that
building software is a hard job should be done by expirienced
maintainers. To much have to be considered.

> I do not want to go into details now, I'd better change ACE in
> REACTOR_SEPARATION branch, and after that I'll be ready to discuss
> proposed solutions. Please supervise my work if you wish to, as
> in configuration management it is very easy to make a mistake.
Ok, I will observe your modifications.

> Do you really does not have to invoke "make qt=1" for building ACE?
No. Because we set all features again for include/makeinclude/platform_macros.GNU
by converting the feature file to a Makefile.

> Then I suppose you patch few files from "include/makeinclude "while
> building debian package (IMHO debian package is one of the bests for ACE).
Modifing the platform_macros.GNU file is not a patch then a proposed way
to configure ACE. We are doing this at build time by converting the MPC
feature file in debian/rules (Debian's way to manufacture new packages).

Maybe it's a patch for you. From my point of view, MPC should do this job
by itself depending on the output format of the Makefiles/projects.

> The additional qt=1 option passed to make (not MPC!) is not necessary.
I think you should consider to convert the $ACE_ROOT/bin/MakeProjectCreater/config/global.features
file the same way Debian is doing. Here is a simple and easy to understand
Makefile rule used by Debian to convert their debian.feature file (a replacement
for global.features):

$(ACE_ROOT)/include/makeinclude/platform_macros.GNU:	$(ACE_ROOT)/debian.features
	sed -e 's/^\/\//#/g' "$^" > "$@"
	echo >> "$@"
	echo "include \$$(ACE_ROOT)/include/makeinclude/platform_linux.GNU" >> "$@"
 
> Moreover, under MSVC after generation of vcproj's one does not have to set
> any additional option, invoking "Build Solution" is just enough to build ACE and
> ACE_QtReactor.
A confirmation to me that MPC should be extended/fixed while generating GNUmakefile
targets with an additional step where definitions of the feature file are applied
to the GNUmakefiles.

> When one considers building ACE distribution only, then additional qt=1 when
> invoking make does not matter, but when one has to develope under linux an
> application using ACE and Qt, then "qt=1" is irritating because it
> does not introduce any additional value (BTW. I know scripts and
> aliases ;-) ).
Yes it is. MPC should be fixed here.

> Neither do I. But there is a difference between MPC features (those
> set in *.features files) and make features (variants) set in make's
> command line.
Leting MPC apply the feature definitions to GNUmakfile (in sence of platform_macros.GNU)
would solve the difference, whould not? This applies only for the GNUmakefile
target I think. Maybe there are more MPC targes have to be considered too?

> I agree. Moreover, it would be better to have ACE already subset in
> cvs, rather than to play with its configuration files individually.
A advantage in subsetting some of the features would be a simple to
build default ACE functionality. The disadvantage would be subsets not
in sync with the MAIN branch. As consequence the release management
and quality assurance are much more time consuming.

For all those features today can be enabled/disabled by options I would
not confirm to subseting ACE in subprojects. If I'm right a improved
MPC version for ACE can solve the GNUmakefile definitions easily.

> Concluding my long letter, from a configuration perspective ACE "GUI" 
> reactors  should be managed almost the same way ACE_SSL is with some
> additional improvements.
Hmm, if I can remember you have to set ssl=1 while calling make (in
the non-Debian way) the same way as make qt=1. ssl is a feature as qt is.

--
Raphael Bossek

--Signature=_Sun__5_Dec_2004_23_30_11_+0100_Gn.M9.zxGr7zzALM
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBs4v1N2lBq4Nesv8RAu2qAJ93/0sf4Exra9LxU9OAmtrfFbOnHwCgu4gS
LwZp4QalzX13H69eQnxB1kk=
=poiZ
-----END PGP SIGNATURE-----

--Signature=_Sun__5_Dec_2004_23_30_11_+0100_Gn.M9.zxGr7zzALM--