Moving boost/static_assert.hpp to Config
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.
On 7 Jan 2026 18:44, Peter Dimov via Boost wrote:
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.
Please, postpone the changes to depinst until we update all the libraries to avoid the dependency on StaticAssert. Then we update depinst and remove the StaticAssert submodule.
Am 07.01.26 um 17:56 schrieb Andrey Semashev via Boost:
Please, postpone the changes to depinst until we update all the libraries to avoid the dependency on StaticAssert. Then we update depinst and remove the StaticAssert submodule. Just to be clear: "remove the submodule" does not mean deleting the library but only not installing it with depinst?
On 7 Jan 2026 20:04, Alexander Grund via Boost wrote:
Am 07.01.26 um 17:56 schrieb Andrey Semashev via Boost:
Please, postpone the changes to depinst until we update all the libraries to avoid the dependency on StaticAssert. Then we update depinst and remove the StaticAssert submodule. Just to be clear: "remove the submodule" does not mean deleting the library but only not installing it with depinst?
No, the submodule will stop being downloaded after depinst is updated (and CI configs, if they happen to have the StaticAssert dependency hardcoded now). "Remove" means remove, i.e. https://github.com/boostorg/static_assert will no longer exist.
Am 07.01.26 um 18:19 schrieb Andrey Semashev via Boost:
On 7 Jan 2026 20:04, Alexander Grund via Boost wrote:
Am 07.01.26 um 17:56 schrieb Andrey Semashev via Boost:
Please, postpone the changes to depinst until we update all the libraries to avoid the dependency on StaticAssert. Then we update depinst and remove the StaticAssert submodule. Just to be clear: "remove the submodule" does not mean deleting the library but only not installing it with depinst? No, the submodule will stop being downloaded after depinst is updated (and CI configs, if they happen to have the StaticAssert dependency hardcoded now).
"Remove" means remove, i.e. https://github.com/boostorg/static_assert will no longer exist. And which of those 2 things are you suggesting? The latter? Because this will surely break many users that rely on e.g. the `Boost::static_assert` CMake target
So at least that should be included in Boost.Config as an alias for Boost::headers/config including the generated (by b2) config files I'm not sure if it is possible to deprecate CMake targets in a way that causes proper warnings/errors, which would be a way forward.
On 7 Jan 2026 20:30, Alexander Grund via Boost wrote:
Am 07.01.26 um 18:19 schrieb Andrey Semashev via Boost:
On 7 Jan 2026 20:04, Alexander Grund via Boost wrote:
Am 07.01.26 um 17:56 schrieb Andrey Semashev via Boost:
Please, postpone the changes to depinst until we update all the libraries to avoid the dependency on StaticAssert. Then we update depinst and remove the StaticAssert submodule. Just to be clear: "remove the submodule" does not mean deleting the library but only not installing it with depinst? No, the submodule will stop being downloaded after depinst is updated (and CI configs, if they happen to have the StaticAssert dependency hardcoded now).
"Remove" means remove, i.e. https://github.com/boostorg/static_assert will no longer exist. And which of those 2 things are you suggesting? The latter?
Both. But not necessarily at the same time (i.e. in the same Boost release).
Because this will surely break many users that rely on e.g. the `Boost::static_assert` CMake target
Users will have to update their dependencies to remove `Boost::static_assert`.
So at least that should be included in Boost.Config as an alias for Boost::headers/config including the generated (by b2) config files
We could do that, in principle, although I would prefer to avoid piling dummy targets with no clear plan to remove them. I'd rather declare the StaticAssert submodule deprecated in release notes of Boost N and then remove it, along with targets, in e.g. N+3.
I'm not sure if it is possible to deprecate CMake targets in a way that causes proper warnings/errors, which would be a way forward.
Yes, if there is a way to generate warnings, that would be great. I'm not aware of one, though.
On 7 Jan 2026 17:56, Peter Dimov via Boost wrote:
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?
My intention was that we update all our dependencies to remove the dependency on StaticAssert. I was going to submit PRs to the affected libraries to that effect, but I haven't got around to do this yet. I still would prefer this way forward.
On Wed, Jan 7, 2026 at 10:48 AM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
My intention was that we update all our dependencies to remove the dependency on StaticAssert. I was going to submit PRs to the affected libraries to that effect, but I haven't got around to do this yet. I still would prefer this way forward.
Good luck, trully, in getting those 36 PRs all the way through to the master branch! I'm still waiting on 33 libraries to merge the modular b2 changes to master after many months. :-( -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supongas Nada -- Robot Dreams - http://robot-dreams.net
On 7 Jan 2026 20:12, René Ferdinand Rivera Morell via Boost wrote:
On Wed, Jan 7, 2026 at 10:48 AM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
My intention was that we update all our dependencies to remove the dependency on StaticAssert. I was going to submit PRs to the affected libraries to that effect, but I haven't got around to do this yet. I still would prefer this way forward.
Good luck, trully, in getting those 36 PRs all the way through to the master branch! I'm still waiting on 33 libraries to merge the modular b2 changes to master after many months. :-(
We have the almighty Peter on board, so I'm optimistic. :)
participants (6)
-
Alexander Grund -
Andrey Semashev -
Ion Gaztañaga -
Peter Dimov -
René Ferdinand Rivera Morell -
Vinnie Falco