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.

[mmarczell-graphisoft]

@sbc100

Just like apt-get install zlib-dev on linux.

Not being familiar with that, does that automatically add the zlib headers to the include path in every subsequent compilation?

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.

This solves the opposite usecase: making the built in boost available for the compilation. My current requirement is: the build should reproducibly break if someone forgets to reference boost in CMake, and still uses boost in the code.

In our case, there was already a boost library included by other means as well, in another module. The builtin boost ending up on the include path invisibly creates the possibility of two different boosts in the same compilation, maybe of different versions.

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

For some years now I had the impression that USE_BOOST_HEADERS adds the boost headers to the include path, and not using the option does not. This is the design that I would recommend. I think it being a compile time option strongly implies the mental model that it is an option affecting the current compilation only.

[sbc100]

Just like apt-get install zlib-dev on linux.

Not being familiar with that, does that automatically add the zlib headers to the include path in every subsequent compilation?

Yes, this is just an example of how you might install package (headers and libraries) into the default path/sysroot on your linux machine.

[sbc100]

Unfortunately, all of the current ports (of which boost is just one of them) do install directly into the emscripten sysroot (which makes them forever available to future compiler invocations. Changing how the ports work so that they did not install into the global location would be pretty big change.

I think I understand you problem now. You want to avoid the usage of any kind of system version of boost in your project and instead always use the bundles version? So if a user on macOS used homebrew to install boost into their system library location you would have similar issue to a user who did -USE_BOOST_HEADERS on emscripten I think?

[sbc100]

I think we can at least update the dos for our ports to mention this persistence.