From: Peter Schueller (schueller.p_at_[hidden])
Date: 2008-04-06 10:38:09
On Sun, Apr 6, 2008 at 11:59 AM, Vladimir Prus <ghost_at_[hidden]> wrote:
> On Sun, 6 Apr 2008 11:45:06 +0200
> "Peter Schueller" <schueller.p_at_[hidden]> wrote:
> > On Sun, Apr 6, 2008 at 6:56 AM, Vladimir Prus <ghost_at_[hidden]> wrote:
> > > 2. If you know for sure that CPP files created with different
> > > value of the feature are identical, and always will be, you have to
> > > remove the feature from the property set associate with the CPP
> > > file.
> > >
> > > The example generator has this code:
> > >
> > > # Produce one output, using just copy.
> > > local a = [ new action $(sources)
> > > : common.copy : $(property-set) ] ;
> > > local t = [ new file-target $(name) : CPP :
> > > $(project) : $(a) ] ;
> > >
> > > which can be modifier as follows:
> > >
> > > local raw = [ $(property-set).raw ] ;
> > > local stripped = [ property.change $(raw) :
> > > <gsoap.usage> ] ; local a = [ new actions $(sources) :
> > > common.copy : [ property-set.create $(stripped) ] ;
> > > local t = [ new file-target $(name) : CPP : $(project)
> > > : $(a) ] ;
> > >
> > >
> > > In this case, the gsoap.usage property won't be associated with the
> > > target and the call to virtual-target.register will no longer
> > > complain that two different targets are associated with the same
> > > filename.
> > >
> > > Note: the above is untested, so some *details* might be wrong. It
> > > should work overall.
> > I only use the property to pass some information to the generator so
> > that the generator can decide which CPP files from the action are
> > passed to the target, i.e. which CPP files get linked into the final
> > LIB or EXE. Therefore I could use the method from above.
> > But this does not work, and I think the reason is the following fact
> > stated in property-set.jam:
> > 13 # - there's 1<->1 correspondence between identity and value. No
> > two instances of
> > 14 # the class are equal. To maintain this property, the
> > 'property-set.create'
> > 15 # rule should be used to create new instances. Instances are
> > immutable.
> > With your method I create two content-wise equal property-sets but
> > virtual-target still gets no instance equality
> This should not happen. property-set.create is exactly the method that
> ensured the 1-1 correspondence between identity and value.
> > and complains about a
> > duplicate target (see attached output.txt)
> > This seems similar to this problem
> > http://lists.boost.org/boost-build/2005/11/12089.php which was fixed
> > in http://svn.boost.org/trac/boost/changeset/31830 but I do not
> > understand how this changeset fixed it and if it applies to my
> > problem.
> Just in case -- are you sure all targets you create get passed via
> If yes, then please send me a minimal complete project that reproduces
> the problem, and I will take a look.
I am quite sure that I don't miss to register a target as virtual
target, perhaps the problem is my usage of generators.construct?
I am sending the complete gsoap.jam and a minimal Jamroot file. To get
my error messages, you need to do "touch foo.wsdl server.cpp
client.cpp ; bjam".
If the <gsoap.usage> is both set to server or both to client there
will be no error messages.
Thanks for your help,
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