|
Boost-Build : |
From: Johannes Brunen (JBrunen_at_[hidden])
Date: 2004-11-22 04:39:59
Hi Volodya,
finally, I have succeeded with the long command line.
I have done the following:
1. msvc.jam
generators.register-c-compiler msvc.compile.c++ : CPP : OBJ RSP(%_cpp) : <toolset>msvc ;
actions compile.c++
{
$(.CC) /Zm800 -nologo -TP -U$(UNDEFS) $(CFLAGS) $(USER_CFLAGS) @"$(<[2]:W)" -c -Fo"$(<[1]:W)"
}
rule compile.c++ ( targets + : sources * : properties * )
{
common.response-file $(targets) : $(sources) : $(targets[2]) : $(properties) ;
}
2. common.jam
rule response-file ( targets + : sources * : the-response-file : properties* )
....
print.text
[ on $(targets[1])
return -D$(DEFINES) -I"$(INCLUDES)"
] ;
}
This works for me, but I don't know if the changes are really correct.
Will the response files be generated either at each activation of bjam or only when the jam files change?
If these changes are correct are they then going into the bbv2 system? Can I expect that future version of bbv2 will
handle long command lines?
Volodya wrote:
> I would be a bit surprised if a single source file required so many includes.
You are right. It is 'of course' not a single source file.
> Maybe the problem is that you're adding all includes to top-level project,
> as opposed to specifying specific needed includes only for subprojects.
I have changed my setup to use only those includes necessary for my subprojects.
However, some of these uses so many INCLUDES and DEFINES that I have still the long
command line problem. Problem is first that we have a partioning of our system which
has been successful used for many years. Secondly, our project is really huge (at least in my thinking).
We have a lot of external libraries in use and are working with roughly 5500 source and header files of our
own. So in conclusion, IMHO, the long command line problem is a real word problem which should be
tackled by a build system (scalability).
However, I really like bbv2 and hope that I can use it for my future work.
With best regards
Johannes
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