Replacing Make for the DMD build

[Russel Winder via Digitalmars-d]

On Mon, 2017-06-19 at 14:52 +0000, Vladimir Panteleev via Digitalmars-d 
wrote:
> 
[…]
> 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.

The usual approach is to leave the old system in place, put the new
system in place, and run in parallel. Then people can remove their
dependency on the old system over time. Then you deprecate the old
system, and then remove it. The new system does not have to replicate
any part of the old system, it just has to produce the end products.

[…]
> 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.

GStreamer seems like a good model here as they have dealt with this
exact same situation (well not exact, they do not have the dlang.org
problem in the same way). As part of their trialling Meson to replace
Autotools, they created a build repository that pulls in all the other
repositories such that the whole structure has a well-defined
architecture, all paths are known. Thus you get a nice simplification
that enables a global build as well as individual repository builds.

Of course they have made the decision to trial on the real
repositories, with the option to delete it all and return to using
Autotools. This has a major benefit, it is the real repositories being
worked on and anyone can chip in at any time.

This approach also leads to earlier "buy in" from more people. Though
in GStreamer case Meson is the natural step on from Autotools, so there
is perhaps less argumentation over options, before heading to a trial.

[…]
> 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.

Possibly, what time are you thinking of? I haven't used IRC, well not
in over 20 years anyway, so I would need data on connecting. 

[…]
-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20170620/ae754470/attachment.sig>