Replacing Make for the DMD build

[Vladimir Panteleev via Digitalmars-d]

On Monday, 19 June 2017 at 14:15:22 UTC, Russel Winder wrote:
> On Mon, 2017-06-19 at 13:44 +0000, Vladimir Panteleev via 
> Digitalmars-d wrote:
>> […]
>> 
>> DMD is insufficient, and is not the hardest makefile to port. 
>> Any serious proposal would need to cover all core repositories 
>> - dmd, druntime, phobos, tools, and dlang.org. We would need 
>> to evaluate any proposals thoroughly, and it will likely 
>> involve a trial period during which both will be maintained in 
>> parallel before any switch-over occurs.
>
> One doesn't port Makefiles, one writes a new build that 
> achieves the same final outcomes.

We will likely need to continue providing shim makefiles which 
invoke the replacement build system for the foreseeable future. 
The big problem here is that all make targets are essentially 
part of their public interface, so if we are to avoid breaking 
anyone's scripts or workflow, they must be kept working. 
Otherwise, I don't disagree.

> If those 5 are so interconnected why are they in separate 
> repositories?

Legacy reasons; prohibitively high cost of migrating to a 
monorepo; higher granularity of specialization for maintainers 
and reviewers of various codebase components, as well as 
assigning permissions to them.

> It should be entirely feasible to replace, and evaluate the 
> replacement of, the builds of each of the repositories 
> independently.

The current build system has a number of problems caused by the 
components being in separate repositories. For example, if you 
change a file in Phobos and want to rebuild the documentation 
(dlang.org), the latter won't know that only a single file 
changed in the former, because the dlang.org makefile is not 
aware of the rules governing the building of Phobos files. 
Furthermore, both the dlang.org makefile and the Phobos makefile 
have a target for building Phobos documentation, but they work in 
different ways and produce different results. A replacement build 
system that can achieve correct interoperability as described 
above would score a lot of points towards being accepted.

More importantly, if we accept a proposal for three repos and on 
the fourth one we run into a blocker (or even the replacement 
simply being very unsatisfying), then that would put us in an 
unpleasant situation. So, I think that requiring working 
replacements for all components makes sense as a prerequisite for 
any single component being switched over to the new build system.

> To demand it is an all or nothing, is to set a bar to high for 
> volunteer labour.

My labour is just as volunteer as yours. I'm not demanding that 
someone presents a complete solution; but neither am I going to 
write one from scratch myself. Which is why I said I'd be 
interested in further discussion and proposals.

Will you have some time to chat about Reggae on IRC tomorrow? I 
should be around about 12 hours from now for about 12 hours since 
then.

> Interestingly I bet the Make-based build didn't have to undergo 
> such review. ;-)

It certainly did not. However, migrating from the status quo to 
the status quo is a no-op and has a cost of zero. Here, we need 
to balance the cost of the migration against the benefits of the 
proposal.

> That the Makefiles are tangled does not imply a proper build 
> should be.

There are many moving parts, and we will keep wanting to add more.