USE_BOOST_HEADERS is incorrectly persistent

[mmarczell-graphisoft]

If you ever once issue a compilation command with -sUSE_BOOST_HEADERS, Boost somehow ends up on the include path of every subsequent compilation. This is unexpected and incorrect, as for example one might want to use a different version of Boost than what is included, leading to incompatibilities or confusing errors.

Reproducing minimal repo at: mmarczell-graphisoft/embug@d846c9e

Reproduction CI run at: https://github.com/mmarczell-graphisoft/embug/actions/runs/23202095356/job/67427039648#step:4:1

Version of emscripten/emsdk:
5.0.3

Failing command line in full:

em++ main.cpp # this fails, correctly 
em++ -sUSE_BOOST_HEADERS main.cpp # this succeeds correctly
em++ main.cpp # this succeeds incorrectly

[sbc100]

The first time you use -sUSE_BOOST_HEADERS it will install the boost headers into the sysroot. So yes, they will visible to all future runs of the compiler.

However, you should still be able to override them using -I/path/to/my/boost which user includes should always take priority.

Changing the location of boost headers to be somewhere that is not-visible-by-default may be possible, but hopefully not necessary as it risks breaking others.

[mmarczell-graphisoft]

In our case it manifested as: "the build breaks on some developer machines as well as on CI, but the one who has committed the code could not reproduce the build breaking". Because he has already USEd_BOOST_HEADERS once, maybe in another project. So he did not add neither USE_BOOST_HEADERS to the CMakelists.txt, nor the other boost target that existed in the project. But the others have not USEd_BOOST_HEADERS before, and CI runs on Github Actions which always starts with a clean slate. So the code using boost has broke the build at everyone else.

I think even if the original design that you described sounds reasonable, the fact that it can create such confusing situations requires that it be fixed.

[sbc100]

You can think of -sUSE_BOOST_HEADERS as a shortcut for ./embuilder build boost_headers. Its kind of like -sUSE_ZLIB is a shortcut for ./embuilder build zlib. This will install libz in the right place such that if you prefer you can then switch to -lz for future builds on the local machine. These things install libz.a in the <sysroot>/usr/lib and <sysroot>/usr/include so there are available ambiently for future calls to the compiler. Just like apt-get install zlib-dev on linux.

All I can recommend is that you ensure that your build process either has ./embuilder build boost_headers as part of the setup phase or -sUSE_BOOST_HEADERS in CFLAGS. Either one should do.

I don't think this is something emscripten easily fix or make simpler, but I am open design ideas if you have any.