cxx-modules-sandbox
cxx-modules-sandbox copied to clipboard
mathstuf
Add build2 configuration
Build2 supports modules. Build support for it would be nice to have for comparison.
Cc: @boris-kolpackov
I took a look at the simple example and have two immediate issues:
-
Module interface units use the same extension (
.cpp) as module implementation units, non-modules, and non-modular code. I believe it's a good idea to distinguish them with a separate extension and would suggest.mpp(to be consistent with.hpp,.cpp, etc). Inbuild2this is a hard requirement. -
Module TU file names don't have any correspondence to module names. I think this is both unrealistic and bad practice to encourage. In the same vein, I would suggest using more meaningful module names instead of
MandI. I've had good results withhello,hello.core,hello.extra.
Module interface units use the same extension (.cpp) as module implementation units, non-modules, and non-modular code. I believe it's a good idea to distinguish them with a separate extension and would suggest .mpp (to be consistent with .hpp, .cpp, etc). In build2 this is a hard requirement.
Why is it a hard requirement? Module code is still C++ code.
Module TU file names don't have any correspondence to module names. I think this is both unrealistic and bad practice to encourage.
Fair enough. However, it is something that should be supported. An explicit test case for such should be done instead of it just being assumed.
Why is it a hard requirement? Module code is still C++ code.
We made it a hard requirement in build2 because we strongly believe this is the right thing to do and we don't want to encourage what we feel is wrong. A could of reasons why we feel this way: it is helpful to distinguish files that are "interfaces" vs implementation-detail (similar to how we do now for headers). Also, if there is a separate implementation file, with the .cpp extension you would have to invent a different file name (something like hello.cpp and hello-impl.cpp). With a module interface extension it becomes simply hello.mpp and hello.cpp. Also note that both Clang and MSVC use a separate (although different) extension for module interfaces. So I think now is a good time to try and agree on something sensible/consistent.
However, it is something that should be supported. An explicit test case for such should be done instead of it just being assumed.
Yes, it is supported and yes, a separate test case is a good idea. I just think normally it makes sense for file names to have some correspondence to module name.
I'll look at adding .mpp extension support to CMake and updating the repository to use the conventions you suggest (though I'll still have a directory using .cpp extensions; build2 can exclude it as unsupported if it wants).
Yes, that sounds reasonable, thanks.
Any chance you can grant me write access to this repository? I could then modify build2-related stuff directly as well as help out with other things (once discussed/agreed upon). For example, I could create simple2 next to exiting simple with the above changes and you can move it to simple if looks good and once CMake can handle it?
Invited. I'd like to get CI up sooner rather than later to ensure things keep working, so doing PRs would still be preferred rather than direct pushes, but direct is OK until #1 is done. Feel free to add an install_build2.sh script to the docker branch too.
@boris-kolpackov Clang has chosen to recognise .cppm as module interface files (i.e. it implies a -xc++-module flag). I too would like to have a more unified convention for filenames.
Yes, I am aware. And MSVC has chosen .ixx. Also note that Clang currently uses .cppm for their flavor of modules which are quite different compared to what's proposed. So it may make sense not to conflate two flavors by reusing the same extension.
In the end, I am ok (for this repository) with any extension as long as it differs from the module implementation units, non-modules, and non-modular code (i.e., .cpp). Personally, I would prefer .mpp over .cppm since it's consistent with the overall naming scheme (.hpp, .cpp, etc).
I've merged CI and added enforcements on the branch that CI must pass before merging can be done (also enforced for adminstrators).
Just some update about clang: the earlier -fmodules option actually had to do with their enhanced precompiled header infrastructure. I may not have followed everything, but I think it's only with the new -f-modules-ts option that it started adding a -xc++-module source type (selected automatically for source files with a .cppm extension). AFAIK, that -f-modules-ts option is following the ISO proprosals. Documentation is unfortunately totally absent.
Would it make sense to add a install_build2.sh step to the Dockerfile ?
Yes, I was planning to look into this when I had a chance, but if you want to take a stab at it, I would be grateful. We can discuss the approach here, if necessary.
I was thinking about a script that downloads the install shell script that you recommand (e.g. https://download.build2.org/0.10.0/build2-install-0.10.0.sh) and try to make it noninteractive with the options --yes --trust 86:BA:D4:DE:2C:87:1A:EE:38:C7:F1:64:7F:65:77:02:15:79:F3:C4:83:C0:AB:5A:EA:F4:F7:8C:1D:63:30:C6 (the certificate fingerprint for cppget.org). This would install the whole set of tools, even the package manager.
Yes, that was my thinking as well! If we want to get a bit fancies, we can use https://download.build2.org/toolchain.sha256 to make it version-independent. It is safe to assume build2-install-*.sh pattern will be stable.
I'd like the Dockerfile to be stable, so explicit version numbers would be preferred.
@mathstuf Hm, wouldn't you want the Dockerfile/CI to use the latest released version of build2? Failed that, we will have to (remember to) update it every time we make a release (which we do quite often these days).
With how modules are changing, I don't forsee every buildsystem/compiler combination being compatible forever. Using explicit versions means that checking out the docker-$date tag on this repo will actually get you the same image every time rather than having to figure out what's wrong.
Yes, the fedora:29 base is a bit rocky, but those I'm assuming the code provided there has ~zero effect on what we're testing here since we're building the compiler and build tools ourselves.
@boris-kolpackov
Hi. I've tried to build the docker image with build2 in it. Unfortunately, some shell script inside build2's bootstrap process relies on the which command, and for reasons I don't know, this command (or shell built-in) is not found in the base fedora image. Maybe we can use command -v instead ?
Here is the log:
install bpkg/manifest{manifest}
+ which b-stage
./build.sh: line 33: which: command not found
@johan-boule I've replaced which with command -v, thanks for the report and the fix suggestion!
The fixed version is for now only available on stage so you will need to use that install script: https://stage.build2.org/0/ (Switching to stage is probably a good idea anyway since I am planning to catch up with the latest GCC modules changes, etc.) The repository cert fingerprint is 37:CE:2C:A5:1D:CF:93:81:D7:07:46:AD:66:B3:C3:90:83:B8:96:9E:34:F0:E7:B3:A2:B0:6C:EF:66:A4:BE:65.
planning to catch up with the latest GCC modules changes
I plan on respinning the image today or tomorrow to include some fixes which have been made upstream in GCC and in my CMake branch. That will allow me to do .mpp in #12.
@mathstuf If you're willing to have a look again at my PR before publishing a new image, that would be a chance to include clang and build2. It's building fine now.
Yep, will do. Seeing if I can't get GCC doing partitions properly right now.
Just in case someone needs it.
The latest beta version string can be obtained with:
curl -sSf https://stage.build2.org/0/toolchain.sha256 | sed -n 's,^.*/build2-install-\(.*\)-stage\.sh$,\1,p'
The latest stable version string with:
curl -sSf https://download.build2.org/toolchain.sha256 | sed -n 's,^.*/build2-install-\(.*\)\.sh$,\1,p'
(notice the -stage suffix difference)