Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2008-04-08 10:53:12


On Sunday 06 April 2008 18:38:09 Peter Schueller wrote:
> 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[1])
> > > > : 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[1]) :
> > > > 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
> > virtual-target.register?
> >
> > 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 the testcase. It appears the the error message is as expected. You
have two targets:

        exe testclient : client.cpp foo.wsdl : <gsoap.usage>client ;
        exe testserver : server.cpp foo.wsdl : <gsoap.usage>server ;

Each causes your generator to be invoked and create an action, so total
of two actions are created.

First action takes foo.wsdl and produces fooSoapH.h and fooSoapClient.cpp
and some other targets. Second action takes foo.wsdl and produces fooSoapH.h
and fooSoapServer.cpp. At this point, Boost.Build notices that there are two
actions that produce fooSoapH.h. Those actions are not identical -- they
produce different set of files. So, BoostBuild decides it does not know
which fooSoapH.h is to use.

The first question here is whether generating fooSoapH.h twice is what you
want. Maybe, there's a separate way to invoke the generator that will produce
just fooSoapH.h?

- Volodya


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