Add build2 configuration

[mathstuf]

Build2 supports modules. Build support for it would be nice to have for comparison.

Cc: @boris-kolpackov

[boris-kolpackov]

I took a look at the simple example and have two immediate issues:

1. 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.

2. 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 M and I. I've had good results with hello, hello.core, hello.extra.

[mathstuf]

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.

[boris-kolpackov]

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.

[mathstuf]

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).

[boris-kolpackov]

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?

[mathstuf]

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.

[johan-boule]

@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.

[boris-kolpackov]

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).

[mathstuf]

I've merged CI and added enforcements on the branch that CI must pass before merging can be done (also enforced for adminstrators).

[johan-boule]

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.

[johan-boule]

Would it make sense to add a install_build2.sh step to the Dockerfile ?

[boris-kolpackov]

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.

[johan-boule]

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.

[boris-kolpackov]

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.