[build2] Is build2 the only build-tool capable of c++20 modules

Wilhelm Meier wilhelm.meier at hs-kl.de
Wed May 10 21:28:32 UTC 2023


On 10.05.23 14:49, Boris Kolpackov wrote:
> Wilhelm Meier via users <users at build2.org> writes:
> 
>> But it looks like nobody is using it ;-)
> 
> Yes, telling the users of build2 that they don't count is a good way
> to make sure they will help you with your problem.

Sorry, that is not what I'm saying.
I'm looking for some information about build2, but there isn't much 
aside from your great manual. Or, I'm using a suboptimal search 
strategie. It is just an observation, not an accusement.

Reading the docs of build2 looks for me VERY promising! And I was very 
glad to see, that there is a tool, that works side-by-side with a 
compiler like gcc.

I'm working in the embedded world and there make is the build tool 
everyone uses ... and cmake. In my opinion make is so simple that it 
couldn't be broken. But cmake is going into the wrong direction.

So, I would like to explore build2 because it looks like it goes into 
the right direction. But please forgive me that I am coming from the 
make viewpoint. But I would like to make a push towards build2 in my 
environment. It just looks promising!

>> I can't find reasonable help to my task converting a header-only library to
>> simply module-interface-units. Well, rewritung the headers to modules is no
>> problem at all. But setting up build2 to generate all the bmi files looks
>> very difficult at least to me.
>>
>> In my opinion the task looks simple:
>>
>> the library consists of a set of module interface files (these files
>> represent a std-library for the AVR target of µC).
>> The are all located in one dir. The is one file std.mpp importing all the
>> partitions of the module std.
>>
>> The user should simply do: import std; (in another project dir).
>>
>> So the task is to generate all the bmi files in the users project dir from
>> the module interface files in the library dir - surely in the correct order,
>> since they are interdependant.
> 
> I think you are approaching this the wrong way. You "just" want to generate
> a bunch of BMIs in the correct order in that "library dir" and then "just"
> use them in that "project dir". That would be the expected approach if you
> were using a build tool (as opposed to a build system) like make.
> 
> But build2 is not a build tool. Or, more precisely, you can use it as just
> a build tool by writing your own recipes/rules like you would do in make.
> But that's not going to be easy to do for C++20 modules (and is probably
> the reason why you are looking into this obscure build system that nobody
> is using instead of "just" using the industry-standard make).

Well, yes, I am willing to learn a new build system. And yes, I might be 
stuck in the old "embedded" world using make. But I have learned the 
lesson, that using modules in C++ one needs a new way to build an artifact.

> And if you want to use build2 as a build system and take advantage of its
> support for C++20 modules, you need to stop thinking in term of "just
> generate a bunch of BMIs in this dir" and think in terms of build2's
> build model, which will likely require you to spend some time reading
> the documentation and/or studying the examples in order to understand
> the conceptual model and how things fit together.

I read the docs. Ok, maybe in a cursory way. I beg your pardon.

But I think it is normal just to start, where one is (in the make world) 
and try to expand his knowledge.

> And, BTW, module name `std` is reserved by the C++ standard so I would
> suggest you use something else.

Well, the thing I try to solve is to convert a heady-only library that 
resembles the stdlib for the AVR plattform. As you surely know, avr-g++ 
does not come with a stdlib. So, one has to roll it's own. We have gone 
this path years ago, and now is the time to convert this to modules. And 
I surely don't want to translate headers, i want to get the full 
advantages of writing modules.

Maybe or not, would you give me some advice how to do that? Please 
consider, that there is / was a directory tree with headers, not all 
like the headers for the stdlib. In our implementation this is a 
header-only library. Most of our µC applications comprise only one (or 
some) implementation files using these headers. Some of these should 
build the module std, others should build the module mcu, others the 
module avr.

I admit, but actually, I have no concrete idea how to convert this to 
module interface units. My first thought was to convert each header into 
a module interface unit. But this looks not feasable, because of 
name-clash in the project dir. But I'm am sure, that you can give me 
best practice, how to do that.

Many thanks,
  Wilhelm



More information about the users mailing list