Re: A proposal for a modern build-system

From: Hassan Sajjad (hassan.sajjad069_at_[hidden])
Date: 2024-03-23 12:16:03

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 <hassan.sajjad069_at_[hidden]>
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 <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
>>
>