[Libreoffice] Platform-specific DLL suffix usefulness

Bjoern Michaelsen bjoern.michaelsen at canonical.com
Mon May 30 01:18:56 PDT 2011

Hi Francois,

On Mon, 30 May 2011 09:40:27 +0200
Francois Tigeot <ftigeot at wolfpond.org> wrote:

> 1. Unify DLLPOSTFIX values. Set it in one common .mk if possible
>   This can be done now

Yes, as long as you are only talking about the li, lx, ss, si type
postfixes of applications and indeed no UNO library accidentally uses
those prefixes too. The gcc3-style postfixes certainly are used for UNO

> 2. Remove DLLPOSTFIX usage in the build system
>   This can be done bit by bit 
>   There is no fundamental reason to keep it for 4.0 but it can well
> be left as-is until then.

At least for gbuild there is a fundamental reason: The gcc3-style
postfixes, the .uno.so, the li/lx-style postfixes and others are all
provided over the same mechanic. I would be a simplification to get rid
of all of those (and even more importantly the special cases like
comphelper who are not even sticking to _any_ of the plethora of naming
schemes). Just renaming the DLLPOSTFIX is indeed a most trivial, atomic
change in gbuild:


Change that and all are renamed. Thus, in gbuild it cant be done
bit-by-bit as it is just one change. However, you will have quite a bit
more work in the old build system (which you will also have to do in
one big change as library names are used in both build systems -- you
cant just change those in one build system).
Another reason why bit-by-bit is a bad idea: Even if you would rename a
single lib at a time (*), each such change would lead to major rebuild
on master for everyone, which should be avoided.
Which is why I would have rather have more stuff migrated to gbuild
(which needs to be done anyway) and do the trivial change there, rather
than investing work in the old build system, just to throw it away with
the gbuild migration anyway.



(*) Which in theory could also be done by making yourself even more
additional work, by first renaming them manually one-by-one hard in

More information about the LibreOffice mailing list