On 06/21/2014 12:59 PM, Stephen Kelly wrote:
Bjørn Roald wrote:
On 06/20/2014 08:55 AM, Vladimir Prus wrote:
On 06/19/2014 11:06 PM, Thomas Suckow wrote:
Or is it only running b2 headers that is the problem?
Maybe I have missed it in the previous conversations, but why have ./b2 headers make the /boost folder at all? When using boost-build, the headers target can add all the include paths for the various projects. If working on a project not using boost-build, generally I would install boost (at the very least into a folder).
That way, you'd have a command line with 100 -I elements, which is rather inconvenient to look at, or run by hand, and can make Windows unhappy,
For info:
CMake solves this on Windows (at least for linking) by creating a file with commandline options, which can be passed to cl command-line as a single filename option. But this solution is a real pain as these temporary files are gone when you want to see what are passed to the compiler. So there is no simple way to trace what is going on when something is not working. Tracing down some problems in cmake on windows has been a real pain due to this.
FYI:
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/Windows.cmake;...
OK, I see. It would have been nice if it just set CMAKE_START_TEMP_FILE to "" for me when I pass VERBOSE=1 to nmake. But that may re-create the possible issues with the command line length that use of temp files is designed to work around. The best thing to do for build systems using such temp files may be simply to list the content of the file after the command line when doing verbose build output. thanks, -- Bjørn