-
-
Notifications
You must be signed in to change notification settings - Fork 24
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. #6
Conversation
…a source in install targets.
- Something I've been meaning to do for far too long now is make the GDB pretty printers auto-loading so you don't have to set up `.gdbinit`. This is now done. I also improved the pretty printers to also pretty print the C result type which can be very useful if working with that type, as it will print the error message in GDB. Experimental Outcome's `status_code` has also gained its own auto-loading GDB pretty printer with display of `strerror()` if the code domain is POSIX or generic.
CI fixes
Hopefully fix issue #300 caused by MSVC changing what diagnostic it prints.
Fix issue #299 GCC 14 warns on use of `_`.
…inning, however it had been mainly intended that C++ would originate Results, they would pass through C, and back into C++. It hadn't really been expected that C would want to do much with Results other than inspect them for happy or sad path. It turns out there is more demand than expected for a more functional Result from within C, so this release adds the power to create Results in success and two types of failure, semantic comparison of Results, and printing of Result messages. You can also wrap a C enum into a quick status code from enum, allowing easy custom C error coding from 100% within C. [The documentation for the C support]({{% relref "../experimental/c-api" %}}) has been updated to reflect the new facilities.
- Outcome.Experimental has had C representation support since the beginning, however it had been mainly intended that C++ would originate Results, they would pass through C, and back into C++. It hadn't really been expected that C would want to do much with Results other than inspect them for happy or sad path. It turns out there is more demand than expected for a more functional Result from within C, so this release adds the power to create Results in success and two types of failure, semantic comparison of Results, and printing of Result messages. You can also wrap a C enum into a quick status code from enum, allowing easy custom C error coding from 100% within C. [The documentation for the C support]({{% relref "../experimental/c-api" %}}) has been updated to reflect the new facilities.
Add missing docs for previous commit.
Fixes to previous commits as found the code didn't link under optimisation.
Fixes to previous commits as found the code didn't link under optimisation.
Fixes to previous commits as found the code didn't link under optimisation.
Fixes to previous commits as found the code didn't link under optimisation.
The PR is not clean. Also any changes applied to this repo will get wiped next automatic rebuild. You should either open the PR against standalone Outcome or let me port the change delta. |
There where changes after I composed my fork. That will get resolved next time I merge into the PR branch.
Given that I can't test the build system in that standalone branch you will have to port the changes to the standalone version. In Predef, where I also have a standalone version, I made the conversion scripts bidirectional. Something to consider for the future? |
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.