|
Boost-Build : |
From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-05-25 01:54:40
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?
> > But then we're back to question when response files should be
> > removed.
> >
> > If fact, I think we can solve that question: if we're creating
> > foo/bar/a.exe, then response file name can be foo/bar/a.rsp, and it
> > won't be deleted if compile fails. So copy/pasting the failed
> > command will still work. The file will be delete after first
> > successfull run. Looks OK to me.
>
> 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'.
If we change response files along the lines of my recent patch (earlier in
this thread), then.....
> as a suffix, but instead do something more like:
>
> cl whatever
> set status=%ERRORLEVEL%
> if %status% EQU 0 ( del foo/bar/a.rsp )
> exit %status%
>
> Two reasons:
>
> 1. It makes the command line shorter
>
> 2. If I want to copy/paste the compilation command, it's easier to
> avoid getting the DEL command by mistake.
... then any command line magic your find reasonable is fine with me.
- Volodya
-- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build V2: http://boost.org/boost-build2
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