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.
