Re: [boost] A proposal for a modern build-system

Hi. Could you please confirm if my proposal is under consideration? If so, when can I expect an update regarding its status? Best, Hassan Sajjad On Sat, Mar 23, 2024 at 3:50 AM Hassan Sajjad wrote:

There is not an immediate need to switch to C++20 modules or header-units. But why miss-out if we can get some compilation speed-up. In-case of header-units, no changes need to be made in source-code. Slow compilation is not a big problem for Boost compared to other projects like UE5 and LibreOffice. However, there is still interest in using C++20 modules and header-units.

...

I don't think that updating a software that works for adding a feature requires more effort that reinvent another build system that must do all the things of the existing one and then also the same new ones. Obviously it depends also on the original software architecture and code, but I can bet that's simpler to update boost build.

If you accept the 'what' part described above, you are wrong in evaluating the 'how' part. The Boost build maintainer could comment on it.

On Fri, Mar 22, 2024 at 11:03 PM Daniele Lupo wrote:

...

On 22/03/2024 18:16, Hassan Sajjad wrote:

If some feature is missing, like support for modules, we can update

...

it if needed

I think this will need some effort. A better alternative could be to use a newer build-system maybe.

I don't think that updating a software that works for adding a feature requires more effort that reinvent another build system that must do all the things of the existing one and then also the same new ones. Obviously it depends also on the original software architecture and code, but I can bet that's simpler to update boost build.

But switching to a build system not widely used and/or tested it has no

...

advantages and a lot of disadvantages and potential problems (cmake and b2 are tested over all kind of computer configuration in the world, even a little percentage of problem can afflict many, many users).

HMake testing is quite extensive but at the moment it is 8/10. I know of 2 bugs. These would be fixed using test test-driven approach i.e. first a failing test-case would be added and then fixed. A production build-system cannot afford any bugs. I am confident that I can deliver such a system in the timeframe quoted and that the transition will be smooth sailing. Again, the biggest advantage compared to the competition is drop-in header-units support which could result in 2.5x speed-up. If this could be added in b2 for cheaper then well and good, otherwise you can consider mine.

I'm sure that everything can be done, but I'm not sure that everything that can be done must be done. In my opinion is reinventing the wheel, even if HMake was already invented by you, because for boost it is. I don't see at the moment anything that cannot be implemented in boost build, if necessary, that requires more effort that create/introduce a new build system from scratch.

There's also another thing to consider, that it's good to add new features only if they are requested from the community. At the moment we didn't see anything like that. Obviously being proactive is always a good idea, but taking the effort for updating boost build, or even changing entirely the build system, for adding features that are not requested and so only very few people will use, it's a waste of time and effort. It's true that I don't read this mailing list very often, but I didn't see anything like that.

When we want to update something, usually it's necessary think about what to change, and only then how to do it. the "what" is missing at the moment in the community, so first there should be discussion like:

- "Oh, I'd like to have boost in new c++ modules" - "Really? That sounds good... Who wants it?" - "Me!" -"Me!" - "Ok, X people wants this feature. They are a lot or are only a few? It's worth to develop such a feature?" - "Let's discuss and decide here"

So we discuss, and only if the community decides that the feature is needed, and the "what" is clear, it's possible to start to think about the "how".

So, for example, we should talk first about the possibility/necessity to have new build features, at high level, and only if we decide that they're worth the effort, we can start to say "ok, and now how can we do it?". And even if the "what" is good, the "how" can be complicated time consuming, so it's also possible that the wanted feature will be discarded or paused for future discussions. It's something that happens often in software development.

So, let's talk about the new build features, let's decide if they are good ideas, and only after that we can start to talk about a new build system instead of updating the existing one.

For those reason, "at this time", I'm not convinced to use a new build system. But if the "what" is good enough, I think that it's something that can be taken into account.

Regards.

Daniele Lupo