Master branch now requires liborcus 0.5.0 or higher.

Michael Stahl mstahl at redhat.com
Mon Apr 22 15:32:01 PDT 2013


On 23/04/13 00:09, Bjoern Michaelsen wrote:
> Hi,
> 
> On Mon, Apr 22, 2013 at 09:56:17PM +0200, Michael Stahl wrote:
>> the only thing the abstractions do here is get in the way.
> 
> I dont quite see how the abstractions play a role for the impact on complexity
> here. You can even play this without the abstractions in gbuild:
> 
> Instead of using the gb_LinkTarget__use_foo voodoo in RepositoryExternal.mk
> (your creation btw ;) ) you _could_ make a long spaghetti-code list of
> ifeq($(OS),foo)s and hardcoded gb_Library_set_ldflags directly in the
> Library_bar.mk that is linking against the external essentially ridding
> yourself of all the abstraction.

you are missing the point entirely.  those abstractions are of course
very valuable (that's why i've implemented them :) and not what i'm
talking about.

what i mean that in order to make all the fancy abstractions in gbuild
work, when you write a makefile for an external library itself (i.e.
ExternalProject and UnpackedTarball) you have to be careful not to do
things that break the abstractions such as trample on the global
namespace, or mess with files that are not integrated in the global
dependency graph, which makes ExternalProject files more difficult to
write than the rather free-form dmake equivalents which often liberally
set "LDFLAGS" etc. variables and exported them.



More information about the LibreOffice mailing list