Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for modular build structure. #426

Open
wants to merge 19 commits into
base: develop
Choose a base branch
from

Conversation

grafikrobot
Copy link
Member

@grafikrobot grafikrobot commented Jul 20, 2024

This is part of the effort to make the Boost libraries "modular" for build and consumption. See https://lists.boost.org/Archives/boost/2024/01/255704.php and https://github.com/grafikrobot/boost-b2-modular/blob/b2-modular/README.adoc for more information.

This PR depends on the following other PRs being merged to both develop and master branches of the respective repos:

This PR will be changed to ready for review, i.e. not draft, when the above are merged. Do not merge this one until that time.

@grafikrobot grafikrobot marked this pull request as ready for review August 18, 2024 15:07
@grafikrobot
Copy link
Member Author

Please review and merge this PR at your earliest convenience.

@mborland
Copy link
Member

@grafikrobot Do the modular changes come with an increase in memory usage? The only failure in the CI is OOM with UBSAN that I have not seen before.

@raffienficiaud
Copy link
Member

I am seeing a "no space left on device" error.

@grafikrobot
Copy link
Member Author

@grafikrobot Do the modular changes come with an increase in memory usage? The only failure in the CI is OOM with UBSAN that I have not seen before.

They don't as they are build system changes only. But if those tests where close to OOM before it's not surprising that it might OOM at any time.

@mborland
Copy link
Member

@grafikrobot Do the modular changes come with an increase in memory usage? The only failure in the CI is OOM with UBSAN that I have not seen before.

They don't as they are build system changes only. But if those tests where close to OOM before it's not surprising that it might OOM at any time.

Build system changes could definitely change the memory consumption. Since test has quite a few dependencies are the build sizes all the same? Were build sizes tested before and after modularity to ensure size parity? Is each dependency dragging in copies of all it's dependencies, or is it like how it used to be where there's just one copy of everything?

@grafikrobot
Copy link
Member Author

@grafikrobot Do the modular changes come with an increase in memory usage? The only failure in the CI is OOM with UBSAN that I have not seen before.

They don't as they are build system changes only. But if those tests where close to OOM before it's not surprising that it might OOM at any time.

Build system changes could definitely change the memory consumption. Since test has quite a few dependencies are the build sizes all the same? Were build sizes tested before and after modularity to ensure size parity? Is each dependency dragging in copies of all it's dependencies, or is it like how it used to be where there's just one copy of everything?

I'm still investigating this but one data point since you asked.. It appears the on-disk build sizes with the modular changes is significantly smaller from before (as in for some test builds 14M vs 50M). I'm trying to figure out the memory size. Which is not easy to do given the various programs that running b2 will launch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants