As discussed last time, Andrey Semashev and I moved boost/static_assert.hpp from StaticAssert to Config in order to reduce nearly everyone's dependencies by one (there's no point pulling an entire repository for just one header file.) However, this presents some issues going forward. If I change depinst.py to properly "know" that boost/static_assert.hpp is now in Config, a lot of things break. That's because many libraries list StaticAssert as a dependency in their build.jam and CMakeLists.txt files, and since it's no longer used, depinst doesn't install it and there are errors. We could in principle go over all these (there are ~54 of them) and fix them, but in my experience, changes that break things internally for us also usually break things for others as well. So... instead, we could name the Config header boost/config/static_assert.hpp, leave boost/static_assert.hpp in StaticAssert, and have it include the Config one. This is going to be a lot less painful; people who care about the dependency would change their includes, whereas those who do not, will not. Opinions?
On Wed, Jan 7, 2026 at 6:57 AM Peter Dimov via Boost <boost@lists.boost.org> wrote:
boost/config/static_assert.hpp,
I much prefer "normalized" headers. That is, that every file conform to the rule "boost/$(lib)/$(file).hpp" Same for libraries, I'm not a fan of these special cases where 3 "libraries" live in a single repository (can't remember which now). These special cases mess up the tooling on the website end as well not just depinst.py Thanks
Am 07.01.26 um 15:56 schrieb Peter Dimov via Boost:
If I change depinst.py to properly "know" that boost/static_assert.hpp is now in Config, a lot of things break. That's because many libraries list StaticAssert as a dependency in their build.jam and CMakeLists.txt files, and since it's no longer used, depinst doesn't install it and there are errors.
We could in principle go over all these (there are ~54 of them) and fix them, but in my experience, changes that break things internally for us also usually break things for others as well.
So... instead, we could name the Config header boost/config/static_assert.hpp, leave boost/static_assert.hpp in StaticAssert, and have it include the Config one. So all code that used `boost/static_assert.hpp` would either need to be updated or still use Boost.StaticAssert? Doesn't sound like an improvement to me.
I don't see how we could break others: They'd continue to use StaticAssert if they are not aware of this change. If they adapt their tooling they have to special case/change that too. Also boost/config/static_assert.hpp doesn't seem to be the right place judging by existing headers. We have boost/cstdint and boost/limits there, not in boost/config and static_assert is similar to those not to the other configuration stuff. So I'd use `boost/static_assert.hpp` Best, Alex
Alexander Grund wrote:
I don't see how we could break others:
In my experience so far, our not seeing how we could break others does not in any way preclude us breaking others. Nearly every change of this sort breaks others. The problem is that we learn why and how only after a release.
Alexander Grund wrote:
Also boost/config/static_assert.hpp doesn't seem to be the right place judging by existing headers. We have boost/cstdint and boost/limits there, not in boost/config and static_assert is similar to those not to the other configuration stuff.
This is all legacy, from the time Boost was monolithic SVN so it didn't matter where headers were. Today, every header that's not "normalized" is a potential problem. That's why depinst has a list of all these, so that it knows what to install. Ideally, everything would be regular and this list wouldn't exist.
Am 07.01.26 um 16:17 schrieb Peter Dimov via Boost:
Alexander Grund wrote:
Also boost/config/static_assert.hpp doesn't seem to be the right place judging by existing headers. We have boost/cstdint and boost/limits there, not in boost/config and static_assert is similar to those not to the other configuration stuff. This is all legacy, from the time Boost was monolithic SVN so it didn't matter where headers were.
Today, every header that's not "normalized" is a potential problem. That's why depinst has a list of all these, so that it knows what to install.
Ideally, everything would be regular and this list wouldn't exist. But `boost/static_assert.hpp` exists already and only there. I don't see people changing all those includes just to avoid downloading a very small library on CI which they (usually) don't even notice.
Alexander Grund wrote:
Am 07.01.26 um 16:17 schrieb Peter Dimov via Boost:
Alexander Grund wrote:
Also boost/config/static_assert.hpp doesn't seem to be the right place judging by existing headers. We have boost/cstdint and boost/limits there, not in boost/config and static_assert is similar to those not to the other configuration stuff. This is all legacy, from the time Boost was monolithic SVN so it didn't matter where headers were.
Today, every header that's not "normalized" is a potential problem. That's why depinst has a list of all these, so that it knows what to install.
Ideally, everything would be regular and this list wouldn't exist. But `boost/static_assert.hpp` exists already and only there. I don't see people changing all those includes just to avoid downloading a very small library on CI which they (usually) don't even notice.
Those who care about it, will. Those who don't, won't. That was what I said.
El 07/01/2026 a las 15:56, Peter Dimov via Boost escribió:
As discussed last time, Andrey Semashev and I moved boost/static_assert.hpp from StaticAssert to Config in order to reduce nearly everyone's dependencies by one (there's no point pulling an entire repository for just one header file.)
However, this presents some issues going forward.
If I change depinst.py to properly "know" that boost/static_assert.hpp is now in Config, a lot of things break. That's because many libraries list StaticAssert as a dependency in their build.jam and CMakeLists.txt files, and since it's no longer used, depinst doesn't install it and there are errors.
What is the error? I mean those libraries that depend on StaticAssert, if the StaticAssert module no longer contains the <boost/static_assert.hpp> header (say StaticAssert is an empty module now after all include/* headers are moved to Config), why do they fail? They should find <boost/static_assert.hpp> because everyone depending on StaticAssert depends con Config... I know I'm missing something... Best, Ion
Ion Gaztañaga wrote:
What is the error?
error: Unable to find file or target named error: '/boost/static_assert//boost_static_assert' error: referred to from project at error: '/__w/boostdep/boost-root/libs/detail' error: could not resolve project reference '/boost/static_assert' https://github.com/boostorg/boostdep/actions/runs/20784697352/job/5969085263...
El 07/01/2026 a las 16:23, Peter Dimov via Boost escribió:
Ion Gaztañaga wrote:
What is the error?
error: Unable to find file or target named error: '/boost/static_assert//boost_static_assert' error: referred to from project at error: '/__w/boostdep/boost-root/libs/detail' error: could not resolve project reference '/boost/static_assert'
https://github.com/boostorg/boostdep/actions/runs/20784697352/job/5969085263...
Is that because b2 searches for some info under folder libs/static_assert (say, build.jam or similar)? I mean, where does the build system expect to find "target name" "/boost/static_assert//boost_static_assert"? Couldn't Config declare that boost_static_assert target for backwards compatibility? Not an expert at all, so maybe what I'm asking is nonsense... Best, Ion
Ion Gaztañaga wrote:
El 07/01/2026 a las 16:23, Peter Dimov via Boost escribió:
Ion Gaztañaga wrote:
What is the error?
error: Unable to find file or target named error: '/boost/static_assert//boost_static_assert' error: referred to from project at error: '/__w/boostdep/boost-root/libs/detail' error: could not resolve project reference '/boost/static_assert'
https://github.com/boostorg/boostdep/actions/runs/20784697352/job/5969085263...
Is that because b2 searches for some info under folder libs/static_assert (say, build.jam or similar)?
I mean, where does the build system expect to find "target name" "/boost/static_assert//boost_static_assert"?
This target name is declared in libs/static_assert/build.jam, exactly like for any other library. The way this works (before the change) is as follows. depinst sees boost/static_assert.hpp. Since the file is called "static_assert.hpp", it assumes it belongs to the library "static_assert", and does "git submodule update static_assert". This downloads the static_assert repo in libs/static_assert. The build.jam there declares the target above. Why this doesn't work after the change: depinst sees that "boost/static_assert.hpp" is an exception and doesn't reside in the static_assert submodule but in the config submodule. It doesn't do "git submodule update static_assert", and libs/static_assert remains an empty subdirectory. Being empty, it doesn't contain build.jam, which consequently doesn't declare the target above. libs/detail/build.jam breaks because it can't find the target. The end.
participants (4)
-
Alexander Grund -
Ion Gaztañaga -
Peter Dimov -
Vinnie Falco