Subject: Re: [Boost-build] How to use generators to CPP and LIB
From: Vladimir Prus (ghost_at_[hidden])
Date: 2009-02-03 04:33:05
On Monday 02 February 2009 20:34:26 Duncan Rance wrote:
> Duncan Rance wrote:
> > Well actually I originally had two generators, but I've been through
> > many iterations!
> > I'm going to have try generators.override etc. in a while, but perhaps
> > it might be clearer if I'm say more about what I'm doing (I've been
> > trying to keep it simple!)
> > Check out this lot:
> > type.register RESRBS : rbs ;
> > type.register RESTXT : txt ;
> > type.register RESOUT : res ;
> > type.register RESDAT : dat ;
> > generators.register-standard resources.gensrc : RESRBS : RESTXT ;
> > generators.register-standard resources.genenumh : RESTXT : H ;
> > generators.register-standard resources.genenumc : H : CPP ;
> > generators.register-standard resources.genrb : RESTXT : RESOUT ;
> > generators.register-composing resources.icupkg : RESOUT : RESDAT ;
> > generators.register-composing resources.pkgdata : RESOUT : LIB ;
> > I start with root.rbs. That gets converted into a txt file (in the ICU
> > project's resource-bundling format -- they chose txt but I guess I
> > could change it.)
> > genenumh creates a big C++ enum declaration in a header file (I want
> > it to be called resourcesEnum.h). genenumc creates the enum's
> > definition, ideally in resourcesEnum.cpp.
> > I've got some dat file targets that are supposed to use gensrc ->
> > genrb -> icupkg.
> > Then there is the libroot.a, which is supposed to come from gensrc ->
> > genrb -> pkgdata.
> > The ambiguity comes about because RESRBS -> RESTXT -> H -> CPP -> OBJ
> > -> LIB clashes with RESRBS -> RESTXT -> RESOUT -> LIB.
> > Hopefully this makes more sense!
> > I'm unsure about the file names. It tries to create a root.h &
> > root.cpp etc., but I don't want it to. And I've got no source at all
> > with resourcesEnum in the name, so perhaps I'm just doing totally the
> > wrong thing!
> > As I say, I'll have a look at the override thing.
> Okay, I've had a whole day looking into this again :(
> I tried creating a RESOURCE-LIB type but got nowhere with that.
Why? Here's what seem to work for me:
import type ;
import generators ;
type.register RESOURCE_LIB : : STATIC_LIB ;
type.register TXT : txt ;
generators.register-standard $(__name__).rlib : TXT : RESOURCE_LIB ;
cp /usr/lib/libiberty.a $(<)
resource-lib x : x.txt ;
exe a : a.cpp x ;
> I tried the overriding thing. Here's what I've got:
> class resource-lib-generator : lib-generator
> rule __init__ ( * : * : * )
> generator.__init__ $(1) : $(2) : $(3) ;
> rule run ( project name ? : property-set : source * )
> if [ $(source).type ] != RESRBS
> local t = [ generators.construct $(project) $(name) : LIB
> : $(property-set) : $(source) ] ;
> return $(t[2-]) ;
> generators.register-standard resources.gensrc : RESRBS : RESTXT ;
> generators.register-standard resources.genrb : RESTXT : RESOUT ;
> generators.register-composing resources.icupkg : RESOUT : RESDAT ;
> generators.register-standard resources.genlib : RESRBS : LIB H CPP ;
> generators.override resources.genlib : builtin.lib-generator ;
> generators.register [ new resource-lib-generator
> resources.resource-lib-generator : RESRBS : LIB H CPP ] ;
> generators.override resources.resource-lib-generator :
> builtin.lib-generator ;
> actions genlib
> perl $(frameworkdir)/genlib.pl $(>) $(<) $(icudir)
> The genlib action is correctly used to create the lib, but I now have
> a problem whereby the next LIB to be built fails with:
> warn: Unable to construct ...
> Because it is trying to use the resource-lib-generator rather than the
I suspect it is because you return $(t[2-]) -- if you want this branch
to be acting like the standard generators, you should be returning $(t).
The first element is usage requirements, so if you have any searched
library anywhere, ignoring the first element will break build.
If this does not help, please prepare a complete testcase as archive and
send it, and I'll take a look.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk