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

[Thomas Girard]

Hello,

(looking for proposed fix you mentioned last week, and replying when I
haven't yet.)

Le 06/06/2010 19:01, Marek Brudka a écrit :
>> 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.

You're right: inline functions and templates are special, and they need
to be special cased. I seem to recall there was a script doing this.
But I don't remember where: it could be in ACE+TAO sources or in an
previous version of Debian packages.

>> 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'll assume this was the proposed patch. In fact there's no need for
this as of now since patch-34 was repaired. Even if it's not the long
term solution I prefer it over adding .so symlinks in a package whose
name does not end in -dev. Indeed doing so means having to play with
Replaces: for many packages to make 5.6.3 -> 5.7.7 transition possible.

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

Ack.

Thomas