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:[email protected] 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
