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.
To rebuild unconditionally, pass -a flag to bjam.
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 [...]
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
As a reference:
bjam --clean to clean.