1.91.0: Boost.Predef checks are no longer installed

[Lastique]

It looks like #1118 have broken installation of Boost.Predef checks when installing Boost.

Here's a full build log:

ubuntu-noble-broken.log

The command line used to install Boost is:

/build/boost/boost/b2 -j16 -q -d2  --layout=system --ignore-site-config --user-config=/build/boost/boost/user-config.jam variant=release debug-symbols=on cxxstd=23-gnu numa=on --prefix=/build/boost/boost/debian/tmp/usr  \
    --libdir=/build/boost/boost/debian/tmp/usr/lib/x86_64-linux-gnu \
    --without-python link=static,shared install

which is at line 42366 in the attached log.

Normally, you would see installation into /build/boost/boost/debian/tmp/usr/share/boost_predef after b2 finishes its configuring work.

Reverting #1118 fixes this.

CC @grisumbras

[nitro404]

I think I'm seeing a similar problem building using VS2022 in x64 with toolset 143 and C++20:
CUSTOMBUILD : error : wrong library name 'predef' in the --without-<library> option.

I'm consuming Boost using Hunter:

hunter_config(Boost
	URL "https://archives.boost.io/release/1.91.0/source/boost_1_91_0.tar.bz2"
	VERSION "1.91"
	SHA1 "9c34db516413241449b664c2e1b5add089515bd6"
)
set(BOOST_COMPONENTS
	random
	regex
)
hunter_add_package(Boost COMPONENTS ${BOOST_COMPONENTS})
find_package(Boost CONFIG REQUIRED ${BOOST_COMPONENTS})
foreach(_BOOST_COMPONENT ${BOOST_COMPONENTS})
	list(APPEND BOOST_LIBRARIES Boost::${_BOOST_COMPONENT})
endforeach()
target_link_libraries(${PROJECT_NAME} PUBLIC ${BOOST_LIBRARIES})

Nothing fancy. This used to work fine with Boost 1.87.

[grisumbras]

Arguably, --without-predef should not work, because those options disable compiled libraries and Predef is header-only. But I understand the need to disable installation of all the extra stuff you don't need.

We should discuss the overall approach to installing special files and how that relates to Boost components that can be listed and disabled on the mailing list. Meanwhile, I'll implement a quick fix.

[Lastique]

@grisumbras While #1139 does fix the problem with Predef, my build still doesn't succeed. This time because Boost.System's CMake config files aren't installed.

ubuntu-noble-broken2.log

I think, #1118 needs to be reverted for the time being. Hardcoding libraries to work around various missing installed files isn't sustainable and doesn't seem right. Library installation should work regardless of whether it is a header-only or compiled library.

[pdimov]

The problem with that is while previous versions showed a "builiding:" list of just the compiled libraries that were actually building, after the modular changes the list now included all the libraries. Which was a bit too much.

[Lastique]

I don't see that as much of a problem, since those header-only libraries might still install something, like Predef and System. And the user should probably be able to disable/explicitly enable those libraries' installation. Eventually, we will be installing library headers (right?), which makes every library installable.

In any case, limiting console output should not prevent library installation.

[pdimov]

In any case, limiting console output should not prevent library installation.

It shouldn't. But this list is not merely console output. It also determines which --with-X and --without-X options are valid. Previous status quo was that these were only valid for compiled libraries, and determined whether a specific library was built and installed. But headers were always installed.

Enabling something like --with-mp11 would imply that we then need to make this work "correctly" (for some definition of correctly), and the user expectation here would probably be that b2 --with-mp11 install ought to install only the Mp11 headers, not everything.

I'm not sure what --without-mp11 is even supposed to do, or whether it's going to be useful for anything.

Eventually, we will be installing library headers (right?)

That's going to present new backward compatibility problems. At present, if you use --with-atomic, you still get the headers for all the libraries, not just for Atomic. And if you use --without-atomic, you don't get the Atomic library (.a .so .lib .dll), but you do get Atomic's headers.

We can safely bet that this behavior is relied upon in who know how many build and packaging scripts.

[Lastique]

If we ever transition to a fully modular structure, --with-X/--without-X will have to mean headers as well. We may try to reduce the breakage downstream somehow, but ultimately, when a user requests a library, he should get one, with headers and all other artifacts. Similarly, when he requests to exclude a library, it should be excluded from build and installation entirely. The existing logic with all headers always installed is a legacy from the monolithic Boost distribution, which we can retain as an option.

[pdimov]

but ultimately, when a user requests a library, he should get one, with headers and all other artifacts.

I don't think it's going to work that way. When you request a library, you get its dependencies as well. That's how it works today with b2, and that's also how it works with CMake, even though it's "fully modular".

[Lastique]

Yes, I implied that the dependencies will get built and installed as well, including headers. The important part is that --with-X/--without-X would control headers as well, so when --with-X is specified and a library is not requested and not one of the dependencies, its headers are not installed. Similarly, when --without-X is specified, X's headers are not installed.

[grisumbras]

That should be possible to do. In fact, a call to boost-install already does intra-project dependency analysis in order to generate CMake config files. And that happens before the build starts, so we could produce a correct list of libraries to build. But --show-libraries will stop working, because the point of that option is to quickly print a list and exit, and constructing the dependency graph for Boost is not quick.