-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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. #854
Conversation
This adds the minimal set of declarations to make it possible to have both legacy non-modular building work with new modular building. It allows incremental addition in libraries to get them ready for modular building. This is a temporary state though. After all libraries, tools, and testing build in this mixed mode another version of the jamroot will be needed to remove the legacy build handling.
Jamroot
Outdated
@@ -149,7 +151,8 @@ constant BOOST_VERSION : 1.85.0 ; | |||
constant BOOST_JAMROOT_MODULE : $(__name__) ; | |||
|
|||
# Allow subprojects to simply `import config : requires ;` to get access to the requires rule | |||
modules.poke : BOOST_BUILD_PATH : $(BOOST_ROOT)/libs/config/checks [ modules.peek : BOOST_BUILD_PATH ] ; | |||
import-search $(BOOST_ROOT)/libs/config/checks ; | |||
import-search $(BOOST_ROOT)/libs/predef/tools/checks ; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this still work if libs/predef
is empty? (In a partial checkout)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this still work if
libs/predef
is empty? (In a partial checkout)
Yes, as it has the same effect as what it replaces. In that it just pokes BOOST_BUILD_PATH
. In the future when individual libraries use import-search /boost/predef/tools/check ;
instead it will work "better" as it will error at that line if it doesn't find the project reference and dir. Instead of erroring later when doing the import predef ;
.
Interesting that you didn't ask about it working or not if libs/config
is empty. Which is also a possibility. ;-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually do remember an occasion on which libs/config
was empty and things failed somewhere, which is why I was reminded to ask. :-)
(That's why depinst always installs libs/config
.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(But libs/config
is needed for more than that - the architecture and address model checks are there. Which is another story; these aren't Boost-specific and need to be in b2 proper.)
Preparing a different PR that allows for an easier to manage transition to replace this one. |
This declares fake/temporary modular projects and top-level targets for header only libraries that have not yet applied the modular changes. It allows for merging such modular changes in any order. And hence avoiding a complicated management of such a DAG merge order.
It's possible to not declare the python tool in a config file. But the status tests require python to run the validation script. This adds the python import to declare default python execution rule. Which will allow it to work when python is generally available. And otherwise not cause errors.
Declare our own b2 feature for valgrind and adding the BOOST_USE_VALGRIND predef. This avoids dependency ordering problems since Beast doesn't depend on Boost.Context. Which is the lib that defines the other valgrind feature. This change is needed to avoid build errors for this PR boostorg/boost#854
Declare our own b2 feature for valgrind and adding the BOOST_USE_VALGRIND predef. This avoids dependency ordering problems since Beast doesn't depend on Boost.Context. Which is the lib that defines the other valgrind feature. This change is needed to avoid build errors for this PR boostorg/boost#854
Close & open for CI to reset. |
I've looked at this, and I don't think I know enough about Jamfiles to make reasonable comments. |
This adjusts the top level stage and install targets to refer to the new modular per-library stage and instal targets if available. It also declares the stage and instal targets for header only libraries that don't have those targets. It makes it possible to fully stage or install at the top level in the mixed-modular transition.
Okay, this is truly now ready. I've now made all the changes to support both not-modular, fully-modular, and everything in between. You can see the testing in these two repos:
|
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: - boostorg/boost#854 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.
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: - boostorg/boost#854 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.
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: - boostorg/boost#854
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: - boostorg/boost#854
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: - boostorg/boost#854
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: - boostorg/boost#854
This adds the minimal set of declarations to make it possible to have both legacy non-modular building work with new modular building. It allows incremental addition in libraries to get them ready for modular building.
This is a temporary state though. After all libraries, tools, and testing build in this mixed mode another version of the jamroot will be needed to remove the legacy build handling.