Re: A proposal for a modern build-system

From: Hassan Sajjad (hassan.sajjad069_at_[hidden])
Date: 2024-03-22 22:50:21

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 <jepessen_at_[hidden]> 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
>