Re: Master branch now requires liborcus 0.5.0 or higher.

Hi,

On Tue, Apr 23, 2013 at 12:32:01AM +0200, Michael Stahl wrote:
> 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.

Riiight, then again if its an external project and you want a throwaway
environment that you can poison to your hearts delight, there is nothing
stopping you from putting a build_wrapper.sh shell script or a build_wrapper.mk
makefile in there and do a trivial:

$(call gb_ExternalProject_get_state_target,foo,build) :
        $(call gb_ExternalProject_run,build,$(SRCDIR)/foo/build_wrapper.mk)

or

$(call gb_ExternalProject_get_state_target,foo,build) :
        $(call gb_ExternalProject_run,build,$(MAKE) -f $(SRCDIR)/foo/build_wrapper.mk)

and then go wild there, right? But looking even at the ExternalProjects with
the longest lines and most lines (e.g.  cppunit, icu, xlst and the orcus one
that was just updated) allmost all the logic is interacting with the
configuration from config_host.mk and almost nothing cares about gbuild.

If we want to make that stuff simpler we need to reduce the number of build
scenarios.

Best,

Bjoern