From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-10-24 05:02:08
Zbynek Winkler <zw-bjam <at> robotika.cz> writes:
> Reece Dunn wrote:
> >Zbynek Winkler <zw-bjam <at> robotika.cz> writes:
> >>If this is true, would it be worth to consider just creating the
> >>response file in the action? I mean that the response file would not be
> >>a target at all, the build engine would never see it... The information
> >>to create the rsp is already there and it would have the right semantic
> >>(recreate the rsp each time the target is rebuild) and we could easily
> >>keep the rsps around...
> >Your idea seems sound in theory, I would need some time to work on the
> >implementation as I only have a limited knowledge of how response files work.
> My knowledge is also limited . But I think that with this approach
> the msvc toolset could very much look like some other toolset that does
> not use rcp (ie. gcc).
Ok, but note that other compilers (such as Metrowerks CodeWarrior) also support
response files. One motivation for having it as a target is that it would be
easy to add response file support to those toolsets that support them. I don't
know how this would look if response files weren't targets.
> The only thing that would differ IMHO would the
> be the actions, so instead of building a really long command line of all
> the options and calling the compiler with it, it would somehow process
> them into a file of our choosing (while not running into the command
> line length limitations - but maybe this is why a new builtin might be
> needed? I don't know.) and reference this file in the final build command.
You shouldn't specify the name of the response flie produced internally. This
would add extra complexity. The name of the response file should be handled in
the same way as it is currently being done (with the name being chosen by BB),
that way, you get the msvc toolset looking like other tools that don't support
RSP files like you mention above.
Oh, wait... this is what you meant ;).
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