Re: A proposal for a modern build-system

From: Daniele Lupo (jepessen_at_[hidden])
Date: 2024-03-22 18:03:24

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