Re: [Boost-build] Enforcing missing properties to cause warning or error messages

From: Peter Schueller (schueller.p_at_[hidden])
Date: 2008-04-05 15:28:53

On Sat, Apr 5, 2008 at 3:27 PM, Vladimir Prus <ghost_at_[hidden]> wrote:
> On Saturday 05 April 2008 11:36:26 Peter Schueller wrote:
...
>  > I am using two standard generators to create a client and a server
>  > version of gsoap code. I have to distinguish between server and client
>  > and so I use  a property as requirement. If I forget to add this
>  > property to the Jamfile, both of the generators will be pruned and I
>  > will only get the message "target could not be constructed".
>  >
>  > The generators are registered the following way:
>  >
>  > 12 generators.register-standard gsoap.soapcpp2 :
>  > 13 WSDL_H : H(%SoapStub) H(%SoapH) CPP(%SoapC) CPP(%SoapClient) :
>  > 14 <gsoap.usage>client ;
>  > 15
>  > 16 generators.register-standard gsoap.soapcpp2 :
>  > 17 WSDL_H : H(%SoapStub) H(%SoapH) CPP(%SoapC) CPP(%SoapServer) :
>  > 18 <gsoap.usage>server ;
>  >
>  > Is it possible to do something like
>  > >generators.register-standard gsoap.error.usage : WSDL_H : CPP :
>  > <gsoap.usage>"" ;
>  > which only applies the rule gsoap.error.usage if the property
>  > gsoap.usage is not given and a CPP needs to be created from a WSDL_H?
>  >
>  > If I do as above I get a generator ambiguity for targets which have
>  > the property set correctly to either server or client.
>
>  You can use the generators.override rule to specify that whenever
>  a "real" generator and the "error" generator appear to be viable, the "error"
>  generator loses. See the definition (and comment) in generators.jam.
>
>  I suppose you plan to emit an error message from your generator's Jam code?

Yes, this is/was my plan. I looked into the override documentation and
it works fine, and now I finally understand how the whale sample
works! :)

This is the interesting part of the error message code:
 48 # Register generator for error message if no <gsoap.usage> was given.
 49 generators.register-standard gsoap.error.usage : : CPP ;
 50
 51 # Let the non-error message generators win over the error message generator
 52 # -> this way whenever <gsoap.usage> is given, the error message
is not created.
 53 generators.override gsoap.soapcpp2 : gsoap.error.usage ;
 54
 55 # If this generator is selected, we can output the error message
and immediately
 56 # exit, this exit happens before anything is built.
 57 rule error.usage ( target : source * : properties * )
 58 {
 59   EXIT "Error: you need to specify <gsoap.usage>client or
<gsoap.usage>server"
 60     "for correctly generating from" $(source) "via soapcpp2" ;
 61 }

But I found another possibility: If I do not define the property as
"free" but as "incidental", Boost.Build will use the first value as a
default and I could create a rule depending on this property value, so
I do no longer need the override. Is this a better solution than the
override with the "free" property?

feature.feature gsoap.usage : not_given server client : incidental ;

At the moment I am looking into the next problem because if I build
two applications, one a server and one a client, I get an error
message because the client part creates some files and the server part
creates some files, and the intersection is not empty:

/usr/share/boost-build/build/virtual-target.jam:976: in
virtual-target.register-actual-name from module virtual-targeterror:
Duplicate name of actual target: <pbin/gcc-3.4/debug>fpSoapC.o
error: previous virtual target { gcc%gcc.compile.c++-fpSoapC.o.OBJ {
gsoap%gsoap.soapcpp2-fpSoapC.cpp.CPP { gsoap%gsoap.wsdl2h-fp.h.WSDL_H
{ ../interface/fp.wsdl.WSDL } } } }
error: created from ./testclient
error: another virtual target { gcc%gcc.compile.c++-fpSoapC.o.OBJ {
gsoap%gsoap.soapcpp2-fpSoapC.cpp.CPP { gsoap%gsoap.wsdl2h-fp.h.WSDL_H
{ ../interface/fp.wsdl.WSDL } } } }
error: created from ./dualcallclient
error: added properties:  <gsoap.usage>server
error: removed properties:  <gsoap.usage>client
/usr/share/boost-build/build/virtual-target.jam:450: in
actualize-no-scanner from module object(file-target)@275

I tried to solve this problem as described in the FAQ but it is not so
easy as it seems, as these two lines still generate the same named OBJ
files in intermediate steps:

 31 lib client_soap : ../interface/fp.wsdl : <gsoap.usage>client ;
 32 lib server_soap : ../interface/fp.wsdl : <gsoap.usage>server ;

I think I need to use the property to adjust the names (or the paths?)
of the generated files. I found the following in the documentation
which seems incorrect to me:

"Non-incidental features are assumed to affect build products, so the
files for targets whose build specification differs in non-incidental
features are placed in different directories as described in "target
paths" below. [ where? ]".

A "free" feature is not "incidental" so the files should be generated
in separate directories, but as <include> is also free I don't think
the documentation is correct in this case.

Could I do something similar to:

gsoap.wsdl2h does WSDL -> WSDL_H
gsoap.soapcpp2 does WSDL_H -> SOAPCPP2_CPP(common)
SOAPCPP2_CPP(server) SOAPCPP2_CPP(client) SOAPCPP_H(common)
gsoap.compose.server does SOAPCPP2_CPP(common) SOAPCPP2_CPP(server) ->
OBJ for <usage>server
gsoap.compose.client does SOAPCPP2_CPP(common) SOAPCPP2_CPP(client) ->
OBJ for <usage>client
gsoap.error.usage exits with an error if <usage> is not given

Thank you and kind regards,
Peter