Reputation: 385
Is there any way to get bjam to build cleanly and consistently? It seems fairly random when it decides to rebuild my libraries and when it decides to simply copy them over from somewhere.
I've tried bjam --clean-all
and bjam --clean
, but it still seems to find the files it needs and instead of recompiling it simply copies them to my stage/lib
folder.
Upvotes: 22
Views: 15978
Reputation: 16746
You can use bjam --clean
. Full invocation instructions for b2 are here.
Upvotes: 7
Reputation: 191
The message
32-bit: yes
is misleading.
It only means that the default compiler (often msvc) has a 32-bit version available.
It does NOT mean that the generated code is not for a 64-bit target (if you put address-model=64
).
--reconfigure
clears the cache and ensures that you get the uncached value (which will still be 32-bit if you have msvc as your default compiler).
And beware: to get a completely clean build after changing the compiler features installed, usually from an update, you must also remove the several cached versions of vcvarsall.bat
at C:\Users\The_User\AppData\Local\Temp
(VS2015 update 3 and very likely update 5 when the location of many system files is slated to be changed, and thus the macros defined by vcvarsall.bat
).
These are names like this:
b2_msvc_14.0_vcvarsall_amd64.cmd
...
Proof of generating a clean copy of these files look like this:
I:\modular-boost\libs\hello_boost\example>b2 -a toolset=msvc-14.0
CRT_IncludePath_x64 = C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt using msvc
...found 1 target...
...updating 1 target...
msvc.write-setup-script C:\Users\paula\AppData\Local\Temp\b2_msvc_14.0_vcvarsall_x86.cmd
...updated 1 target...
...found 1 target...
...updating 1 target...
msvc.write-setup-script C:\Users\paula\AppData\Local\Temp\b2_msvc_14.0_vcvarsall_amd64.cmd
...updated 1 target...
...found 1 target...
...updating 1 target...
msvc.write-setup-script C:\Users\paula\AppData\Local\Temp\b2_msvc_14.0_vcvarsall_x86_arm.cmd
...updated 1 target...
If you do not have a clean copy, the 'cached' version of vsvarsall.bat
will be used, perhaps producing cruelly confusing messages about files that do exist like:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\crtdefs.h(10): fatal error C1083: Cannot open include file: 'corecrt.h': No such file or directory
Upvotes: 6
Reputation: 466
bjam -a
and bjam --clean
(only) seem to clean up intermediate files and resultulting binaries, but not the build configuration - according to the manual this is unintentional:
Configuration results are cached - if you try rebuilding with different compiler options then add an "-a" to the bjam command line to force all targets to be rebuilt.
Example (as of boost 1.61 and many releases before):
When I build with address-model=32
, then run it again with 64, it tells me:
32-bit: yes (cached)
In other words, bjam prefers cached values over the options that I pass. Always. -a
and --clean
don't change this unorthodox (buggy?) behavior.
Therefore, whenever you change the parameters passed to bjam, it is probably a good idea to delete the cache file (as Rik mentioned) before building. Thus, my build script looks somewhat like this:
rm -f 'bin.v2/project-cache.jam'
./bjam -a $options [...]
Upvotes: 6
Reputation: 736
As a reference:
bjam --clean
to clean.Upvotes: 6