[Pkg-ace-devel] Plan for ACE+TAO upload

Marek Brudka mbrudka at aster.pl
Sun Jun 6 17:01:39 UTC 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

W dniu 05.06.2010 11:12, Thomas Girard pisze:
> I believe if an header contains a class declaration flagged with an
> _Export macro, then we should distribute it. Otherwise the header is
> not needed; since linking with this class would not be possible under
> Windows for instance (and I think it could also be marked as hidden
> with g++).
I cannot agree in general, that files with _Export declaration
specifier n  are not needed. Please consider for example a header with
inline functiom or templates. In particular this statement may be true
for ACE/TAO, but I do not dare to declare this for sure. Please, give
me some examples of such headers to eventually find another way to
discriminate between necessary and obsolete  files.
> Since I'm about to move back to Paris, I would really like to upload a
> first experimental package this week-end. Any blocker from your point
> of view?
No, please upload packages. I think that changelog fo 5.7.7-1 is
currently fat enough to start the entry for 5.7.7-2 :)

The only problem is with Service_Configuration framework and new
versioning scheme. Currently, runtime packages which contains
libname-*.so libraries only are not sufficient to use dynamic
services. But if one may start using this framework by installing
development packages with libname.so links to libname-*.so. Maybe, we
should temporarily move libname.so links to runtime packages until
more serious patches are provided? I can commit modified install files
if you agree.

I looked at sources once again and examined DYNAMIC_SERVICE_MACRO.
Modification of these macros solves that problem partially, namely
 enables to load plugins from c++ source. However, AFAIK the main use
case for dynamic services is not loading them from source files, as it
is usualy better to just link with them, but to load/remove DLLs using
some external configuration files (svc.conf). The way to enable this
as well as ensure backward compatibility is to modify get_dll_names.
But as this change needs some elaboration I propose to consider it as
non-blocking and publish new package edition.

Marek

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJMC9RyAAoJED+r15Q8F6CGH9YH/R57EmEacSyCqArmezHXA1Cs
5wg693JTU+Rmrleh3zLftjfYq29PmS6nmHQv8eoEhcUtNmBM/x0uMO/F8FFzRT1P
mGLviKeUaOsk9hCesoEZwTSa4pXRge5ikhaYJxGbHsCn+HmdOBiHumP/mo4EUkIV
kCvfzdcEPp2lSxSryp7imewkZnYFwYzUDprfDhmWc+QkNa5lU+mmT3f0w35sNPF/
Oj55ahKHxfHRPst8/n0tdxnSG2GVeaYhdy9fMC5xO4wCGwnHb10IRrKZPO5I8h3+
j56uh/ebRRQb76a+4Q+86jmYZISNxmXvLzxsukYioduYd14850Fi414HClsNCIo=
=eVah
-----END PGP SIGNATURE-----



More information about the Pkg-ace-devel mailing list