Hi there, I was just trying to compile 1.43 on Windows 64 bit for some hours now and unfortunately from my perspective it looks like the modified build system may be a bit broken. First of all, bootstrap.bat didn't work anymore. As usual I was using it to create bjam.exe but this time it just went into causing heavy load and after about 15 minutes it returns telling me the command line is too long. As always, I just did this: ./bootstrap.sh This used to work but not anymore. So I downloaded a precompiled bjam.exe (3.18) and went with that instead. Alas, it created a 32 bit build just fine but failed to produce a 64 bit build. It appears like it is compiling all objects for 64 bit but then tries to link with /MACHINE:X86 , causing the linker to complain: ... common.mkdir bin.v2\libs\math\config\msvc-8.0\debug\threading-multi compile-c-c++ bin.v2\libs\math\config\msvc-8.0\debug\threading-multi\has_long_double_support.obj has_long_double_support.cpp compile-c-c++ bin.v2\libs\math\build\msvc-8.0\debug\threading-multi\sph_neumannf.obj sph_neumannf.cpp msvc.link.dll bin.v2\libs\math\build\msvc-8.0\debug\threading-multi\boost_math_tr1f-vc80-mt-gd-1_43.dll bin.v2\libs\math\build\msvc-8.0\debug\threading-multi\assoc_laguerref.obj : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86' call "C:\Program Files (x86)\Microsoft Visual Studio 8\VC\BIN\amd64\vcvarsamd64.bat" x86 >nul link /NOLOGO /INCREMENTAL:NO /DLL /DEBUG /MACHINE:X86 /subsystem:console /out:"bin.v2\libs\math\build\msvc-8.0\debug\thr eading-multi\boost_math_tr1f-vc80-mt-gd-1_43.dll" /IMPLIB:"bin.v2\libs\math\build\msvc-8.0\debug\threading-multi\boost_m ath_tr1f-vc80-mt-gd-1_43.lib" @"bin.v2\libs\math\build\msvc-8.0\debug\threading-multi\boost_math_tr1f-vc80-mt-gd-1_43 .dll.rsp" if %ERRORLEVEL% NEQ 0 EXIT %ERRORLEVEL% ...failed msvc.link.dll bin.v2\libs\math\build\msvc-8.0\debug\threading-multi\boost_math_tr1f-vc80-mt-gd-1_43.dll bin.v2 \libs\math\build\msvc-8.0\debug\threading-multi\boost_math_tr1f-vc80-mt-gd-1_43.lib bin.v2\libs\math\build\msvc-8.0\debu g\threading-multi\boost_math_tr1f-vc80-mt-gd-1_43.pdb... ... I've tried all sorts of command lines and user-config.jam I could think of, but no effect. Here's what I usually do: ./bjam.exe --architecture=amd64 --address-model=64 -j2 link=shared threading=multi variant=debug,release stage Please let me add that I've been doing this since 1.34 and somehow always managed to get the job done so I have reason to assume there's something that must have changed in this release that broke it. I also tried the switch ---architechture=amd64 and many others I thought might help. I also delete everything already compiled before retrying. The system is Windows XP, current SP and MSVC 8, also current SP. Here's my user-config.jam: ...... using msvc : 8.0 : "C:\\Program Files (x86)\\Microsoft Visual Studio 8\\VC\\BIN\\amd64\\cl.exe" : <setup>"C:\\Program Files (x86)\\Microsoft Visual Studio 8\\VC\\BIN\\amd64\\vcvarsamd64.bat" ; using python : 2.5 ; # Make both versions of Python available using python : 2.5 : "C:\\Program Files\\Python25_64\\python.exe" : "C:\\Program Files\\Python25_64\\include" : "C:\\Program Files\\Python25_64\\libs" : <toolset>msvc ; ....... I also tried to copy the 'tools' folder from 1.42 where it used to work and also the Jamroot and project-config.jam but it still produced the same error. Can anyone give me a hint if there's an issue with the build system in this release? Cheers, Stephan
Again: On Tue, May 11, 2010 at 4:41 PM, Stephan Menzel <stephan.menzel@gmail.com> wrote:
I've tried all sorts of command lines and user-config.jam I could think of, but no effect. Here's what I usually do:
./bjam.exe --architecture=amd64 --address-model=64 -j2 link=shared threading=multi variant=debug,release stage
As always, I didn't try the one that mattered and only _after_ my post: linkflags="/MACHINE:x64" And it works. I never knew this one existed, and I suppose it should have been set by the toolset itself. So I guess this is indeed a bug, right? HTH, Stephan
Stephan Menzel wrote:
Again:
On Tue, May 11, 2010 at 4:41 PM, Stephan Menzel <stephan.menzel@gmail.com> wrote:
I've tried all sorts of command lines and user-config.jam I could think of, but no effect. Here's what I usually do:
./bjam.exe --architecture=amd64 --address-model=64 -j2 link=shared threading=multi variant=debug,release stage
As always, I didn't try the one that mattered and only _after_ my post:
linkflags="/MACHINE:x64"
And it works. I never knew this one existed, and I suppose it should have been set by the toolset itself. So I guess this is indeed a bug, right?
Probably not -- you command line appears to be wrong. Neither --architecture=amd64 nor --address-model=64 ever worked. If you try: ./bjam.exe architecture=amd64 address-model=64 -j2 link=shared does it behave better? - Volodya
On Tue, May 11, 2010 at 5:07 PM, Vladimir Prus <ghost@cs.msu.su> wrote:
Probably not -- you command line appears to be wrong. Neither --architecture=amd64 nor --address-model=64 ever worked. If you try:
./bjam.exe architecture=amd64 address-model=64 -j2 link=shared
does it behave better?
Not really. It tells me amd64 is not a valid architecture. But without it, just with the address-model=64, it works. Gees, so it looks like it's my fault after all. As it so often is. So sorry to bother you. On the other hand, perhaps bjam should complain about non-existing switches... Cheers, Stephan
On 5/21/2010 11:49 AM, Beman Dawes wrote:
On Tue, May 11, 2010 at 11:14 AM, Stephan Menzel <stephan.menzel@gmail.com> wrote:
... perhaps bjam should complain about non-existing switches...
That would add considerably to robustness.
Any possibility of adding a check for non-existent switches?
Sorry I overlooked this thread.. Which switches are you referring to? Switches given to bjam? To the toolsets? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On Fri, May 21, 2010 at 12:59 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
On 5/21/2010 11:49 AM, Beman Dawes wrote:
On Tue, May 11, 2010 at 11:14 AM, Stephan Menzel <stephan.menzel@gmail.com> wrote:
... perhaps bjam should complain about non-existing switches...
That would add considerably to robustness.
Any possibility of adding a check for non-existent switches?
Sorry I overlooked this thread.. Which switches are you referring to? Switches given to bjam? To the toolsets?
IIUC, the OP used this command line after a booststrap: ./bjam.exe --architecture=amd64 --address-model=64 -j2 link=shared ... and Volodya replied that "Neither--architecture=amd64 nor --address-model=64 ever worked." Thus the comment about the possibility of adding a check for non-existent switches. Providing some options that require no "-', some that require "-", and some that require "--" may make sense from an internal perspective, but this is terribly confusing to the user. So the user often makes mistakes. To have the mistakes silently ignored makes it difficult or impossible for the ordinary user. --Beman
On 5/21/2010 1:06 PM, Beman Dawes wrote:
On Fri, May 21, 2010 at 12:59 PM, Rene Rivera<grafikrobot@gmail.com> wrote:
On 5/21/2010 11:49 AM, Beman Dawes wrote:
On Tue, May 11, 2010 at 11:14 AM, Stephan Menzel <stephan.menzel@gmail.com> wrote:
... perhaps bjam should complain about non-existing switches...
That would add considerably to robustness.
Any possibility of adding a check for non-existent switches?
Sorry I overlooked this thread.. Which switches are you referring to? Switches given to bjam? To the toolsets?
IIUC, the OP used this command line after a booststrap:
./bjam.exe --architecture=amd64 --address-model=64 -j2 link=shared ...
and Volodya replied that "Neither--architecture=amd64 nor --address-model=64 ever worked."
Thus the comment about the possibility of adding a check for non-existent switches.
Providing some options that require no "-', some that require "-", and some that require "--" may make sense from an internal perspective, but this is terribly confusing to the user. So the user often makes mistakes. To have the mistakes silently ignored makes it difficult or impossible for the ordinary user.
Ah, yes, we've had that come up before.. Unfortunately the "--" options are an open set. So it's rather hard to actually detect when those are non-existent. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
AMDG Rene Rivera wrote:
On 5/21/2010 1:06 PM, Beman Dawes wrote:
IIUC, the OP used this command line after a booststrap:
./bjam.exe --architecture=amd64 --address-model=64 -j2 link=shared ...
and Volodya replied that "Neither--architecture=amd64 nor --address-model=64 ever worked."
Thus the comment about the possibility of adding a check for non-existent switches.
Providing some options that require no "-', some that require "-", and some that require "--" may make sense from an internal perspective, but this is terribly confusing to the user. So the user often makes mistakes. To have the mistakes silently ignored makes it difficult or impossible for the ordinary user.
Ah, yes, we've had that come up before.. Unfortunately the "--" options are an open set. So it's rather hard to actually detect when those are non-existent.
Is there some way that we could mark options as used? Could we require everything to go through the options module instead of doing a raw match against ARGV? At least, would it be reasonable to warn about arguments that would look like properties if they didn't have the --? In Christ, Steven Watanabe
On Fri, May 21, 2010 at 12:52 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
Rene Rivera wrote:
On 5/21/2010 1:06 PM, Beman Dawes wrote:
IIUC, the OP used this command line after a booststrap:
./bjam.exe --architecture=amd64 --address-model=64 -j2 link=shared ...
and Volodya replied that "Neither--architecture=amd64 nor --address-model=64 ever worked."
Thus the comment about the possibility of adding a check for non-existent switches.
Providing some options that require no "-', some that require "-", and some that require "--" may make sense from an internal perspective, but this is terribly confusing to the user. So the user often makes mistakes. To have the mistakes silently ignored makes it difficult or impossible for the ordinary user.
Ah, yes, we've had that come up before.. Unfortunately the "--" options are an open set. So it's rather hard to actually detect when those are non-existent.
Is there some way that we could mark options as used? Could we require everything to go through the options module instead of doing a raw match against ARGV? At least, would it be reasonable to warn about arguments that would look like properties if they didn't have the --?
We have a library in Boost to handle all this, why is it itself not used? If it is because of missing functionality, that indicates something in that library that should be fixed. As I recall, program_options also warns about incorrect flags.
On 5/21/2010 8:53 PM, OvermindDL1 wrote:
On Fri, May 21, 2010 at 12:52 PM, Steven Watanabe<watanabesj@gmail.com> wrote:
AMDG
Rene Rivera wrote:
On 5/21/2010 1:06 PM, Beman Dawes wrote:
IIUC, the OP used this command line after a booststrap:
./bjam.exe --architecture=amd64 --address-model=64 -j2 link=shared ...
and Volodya replied that "Neither--architecture=amd64 nor --address-model=64 ever worked."
Thus the comment about the possibility of adding a check for non-existent switches.
Providing some options that require no "-', some that require "-", and some that require "--" may make sense from an internal perspective, but this is terribly confusing to the user. So the user often makes mistakes. To have the mistakes silently ignored makes it difficult or impossible for the ordinary user.
Ah, yes, we've had that come up before.. Unfortunately the "--" options are an open set. So it's rather hard to actually detect when those are non-existent.
Is there some way that we could mark options as used? Could we require everything to go through the options module instead of doing a raw match against ARGV? At least, would it be reasonable to warn about arguments that would look like properties if they didn't have the --?
We have a library in Boost to handle all this, why is it itself not used? If it is because of missing functionality, that indicates something in that library that should be fixed. As I recall, program_options also warns about incorrect flags.
Yeah.. Except bjam is written in "C" ;-) And even if it where in C++, which I'm considering doing, the nature of bjam as an interpreted ad-hoc modular language interpreter doesn't lend itself to pre-declaring such options. But what Steven suggest is the only way I've though about to handle it. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On Fri, May 21, 2010 at 8:41 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
On 5/21/2010 8:53 PM, OvermindDL1 wrote:
On Fri, May 21, 2010 at 12:52 PM, Steven Watanabe<watanabesj@gmail.com> wrote:
AMDG
Rene Rivera wrote:
On 5/21/2010 1:06 PM, Beman Dawes wrote:
IIUC, the OP used this command line after a booststrap:
./bjam.exe --architecture=amd64 --address-model=64 -j2 link=shared ...
and Volodya replied that "Neither--architecture=amd64 nor --address-model=64 ever worked."
Thus the comment about the possibility of adding a check for non-existent switches.
Providing some options that require no "-', some that require "-", and some that require "--" may make sense from an internal perspective, but this is terribly confusing to the user. So the user often makes mistakes. To have the mistakes silently ignored makes it difficult or impossible for the ordinary user.
Ah, yes, we've had that come up before.. Unfortunately the "--" options are an open set. So it's rather hard to actually detect when those are non-existent.
Is there some way that we could mark options as used? Could we require everything to go through the options module instead of doing a raw match against ARGV? At least, would it be reasonable to warn about arguments that would look like properties if they didn't have the --?
We have a library in Boost to handle all this, why is it itself not used? If it is because of missing functionality, that indicates something in that library that should be fixed. As I recall, program_options also warns about incorrect flags.
Yeah.. Except bjam is written in "C" ;-) And even if it where in C++, which I'm considering doing, the nature of bjam as an interpreted ad-hoc modular language interpreter doesn't lend itself to pre-declaring such options. But what Steven suggest is the only way I've though about to handle it.
<fanciful-ideas> Well if it was re-written, and felt like rewriting the bjam source too, the latest Spirit has developed an infinitely extensible S-Expression based language designed for such C++ embedding as an example. </fanciful-ideas>
Hi OvermindDL1! OvermindDL1 wrote:
<fanciful-ideas> Well if it was re-written, and felt like rewriting the bjam source too, the latest Spirit has developed an infinitely extensible S-Expression based language designed for such C++ embedding as an example. </fanciful-ideas>
While the idea looks truly attractive to me, I have doubts over its practicality. The following is listed among the most important features in the Overview page of Boost.Build: "Standalone. Boost.Build's only dependency is a C compiler, so it's easy to setup. You can even include all of Boost.Build in your project. Boost.Build does not depend on C++ Boost in any way." Copied from http://www.boost.org/boost-build2/index.html Also, I now remember reading this a while ago: https://svn.boost.org/trac/boost/milestone/Boost.Jam%204.0.0 Another thing to note is that building bjam from source is currently an *impressively* fast operation; that property would surely be lost had bjam been reimplemented based on Boost.Spirit. OTOH, as building of bjam itself is relatively infrequent, I would trade the speed of building bjam for the speed of building my projects *with* bjam any day. Thinking aloud, Gevorg
On 5/22/2010 7:24 AM, Gevorg Voskanyan wrote:
Hi OvermindDL1!
OvermindDL1 wrote:
<fanciful-ideas> Well if it was re-written, and felt like rewriting the bjam source too, the latest Spirit has developed an infinitely extensible S-Expression based language designed for such C++ embedding as an example. </fanciful-ideas>
While the idea looks truly attractive to me, I have doubts over its practicality. The following is listed among the most important features in the Overview page of Boost.Build:
"Standalone. Boost.Build's only dependency is a C compiler, so it's easy to setup. You can even include all of Boost.Build in your project. Boost.Build does not depend on C++ Boost in any way."
Copied from http://www.boost.org/boost-build2/index.html
Also, I now remember reading this a while ago: https://svn.boost.org/trac/boost/milestone/Boost.Jam%204.0.0
Another thing to note is that building bjam from source is currently an *impressively* fast operation; that property would surely be lost had bjam been reimplemented based on Boost.Spirit. OTOH, as building of bjam itself is relatively infrequent, I would trade the speed of building bjam for the speed of building my projects *with* bjam any day.
I've just about changed my mind on those two counts.. Precisely because of that *runtime* speed tradeoff. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Rene Rivera wrote:
On 5/22/2010 7:24 AM, Gevorg Voskanyan wrote:
[snip]
"Standalone. Boost.Build's only dependency is a C compiler, so it's easy to setup. You can even include all of Boost.Build in your project. Boost.Build does not depend on C++ Boost in any way."
Copied from http://www.boost.org/boost-build2/index.html
Also, I now remember reading this a while ago: https://svn.boost.org/trac/boost/milestone/Boost.Jam%204.0.0
Another thing to note is that building bjam from source is currently an *impressively* fast operation; that property would surely be lost had bjam been reimplemented based on Boost.Spirit. OTOH, as building of bjam itself is relatively infrequent, I would trade the speed of building bjam for the speed of building my projects *with* bjam any day.
I've just about changed my mind on those two counts.. Precisely because of that *runtime* speed tradeoff.
Very interesting... I'd very much like to see Boost.Build speed improved. So if there is anything I can do to help achieving that, I'll be happy to contribute! Thanks, Gevorg
On Sat, May 22, 2010 at 7:34 AM, Gevorg Voskanyan <v_gevorg@yahoo.com> wrote:
Rene Rivera wrote:
On 5/22/2010 7:24 AM, Gevorg Voskanyan wrote:
[snip]
"Standalone. Boost.Build's only dependency is a C compiler, so it's easy to setup. You can even include all of Boost.Build in your project. Boost.Build does not depend on C++ Boost in any way."
Copied from http://www.boost.org/boost-build2/index.html
Also, I now remember reading this a while ago: https://svn.boost.org/trac/boost/milestone/Boost.Jam%204.0.0
Another thing to note is that building bjam from source is currently an *impressively* fast operation; that property would surely be lost had bjam been reimplemented based on Boost.Spirit. OTOH, as building of bjam itself is relatively infrequent, I would trade the speed of building bjam for the speed of building my projects *with* bjam any day.
I've just about changed my mind on those two counts.. Precisely because of that *runtime* speed tradeoff.
Very interesting... I'd very much like to see Boost.Build speed improved. So if there is anything I can do to help achieving that, I'll be happy to contribute!
Well as a pure interesting-idea type thing, perhaps a toybjam project, just to see if we could get any runtime power/speed in exchange for compile-time. Can add new abilities such as multi-threaded to scan multiple directories at the same time, among other features. May not ever be used, but in any case it would make for a fascinating case project for Spirit and maybe LLVM too.
On Sun, May 23, 2010 at 3:48 AM, OvermindDL1 <overminddl1@gmail.com> wrote:
Well as a pure interesting-idea type thing, perhaps a toybjam project, just to see if we could get any runtime power/speed in exchange for compile-time. Can add new abilities such as multi-threaded to scan multiple directories at the same time, among other features. May not ever be used, but in any case it would make for a fascinating case project for Spirit and maybe LLVM too.
Well, this thread moved away from the original command line option topic, so even though this is certainly a JHWH question: Didn't you want to move to CMake? Me for one, I would really appreciate it since meanwhile we do almost everything with CMake and boost is the only library left with an own solution, which makes it quite hard to create builds each time a new (or patched) version appears. Besides, it would probably integrate nicer in our projects. Of course these are not really smashing good arguments but still... isn't it worth considering? Cheers, Stephan
participants (7)
-
Beman Dawes -
Gevorg Voskanyan -
OvermindDL1 -
Rene Rivera -
Stephan Menzel -
Steven Watanabe -
Vladimir Prus