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. _______________________________________________ LibreOffice mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice
