|
Boost-Build : |
From: David Abrahams (dave_at_[hidden])
Date: 2005-05-25 08:41:10
Vladimir Prus <ghost_at_[hidden]> writes:
> On Tuesday 24 May 2005 20:12, David Abrahams wrote:
>
>> > And the most convenient way is core support, so that
>> >
>> > actions
>> > {
>> > cl.exe @@($(INCLUDES))
>> > }
>> >
>> > will expand to
>> >
>> > cl.exe @some_file.rsp
>> >
>> > response file when command line length run of of some limit,
>> > and expand to just
>> >
>> > cl.exe $(INCLUDES)
>> >
>> > otherwise.
>>
>> Yes, that would work.
>
> Do you think that's the best approach?
Well, I am reluctant to add more stuff to the core -- that'll just
make porting to Python a bit harder -- but in order to get maximal
usability we might need to do it. I think you have to watch out that
your response files don't collide with some file the user
intentionally generates with a .rsp extension, but I'm not sure how
you'd do that. Anyway, that's not a new problem; it exists even for
non-core approaches.
So, I'm on the fence about whether it's best. But it's at least as
good as any other approach ;-)
Do you feel confident that "@@(...)" is a good syntax? I presume you could
put anything at all in the parens, e.g.
@@(-I$(INCLUDES) -D$(DEFINES) $(>))
>> I would like to *not* use
>>
>> && del foo/bar/a.rsp
>
> Well, if response files are supported in core, there would be no need to
> add any explicit 'del'.
Okay.
> If we change response files along the lines of my recent patch
> (earlier in this thread), then.....
Sorry, I don't know what patch you're referring to. If you made it
already, what's to change?
-- Dave Abrahams Boost Consulting www.boost-consulting.com
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