How do I force bjam in boost to build cleanly and consistently?

Question

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.

Solution 1

To rebuild unconditionally, pass -a flag to bjam.

Solution 2

You can use bjam --clean. Full invocation instructions for b2 are here.

Solution 3

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

Solution 4

As a reference:

1. bjam --clean to clean.
2. go into bin.v2 folder and delete project cache file if necessary

Solution 5

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 [...]

View more solutions

Comments

[Adam Trhon]

This is not the same as clean. After clean I can build half of the project, fix compile error, then build the other half. With -a I have to build the first half twice.

[Bogdan]

the link is broken now

[sehe]

This still keeps the configuration cache

[sehe]

This still keeps the configuration cache

[sehe]

The only answer that mentions the cache. Thank you

[sehe]

Okay, a second answer that mentions the cache. Too bad it is written as a reply to existing answers, but the added explanations are top notch. Thanks.