Re: scripts/build/scan-mf-deps: script to generate MF dependencies (issue 553700043 by address@hidden)

[hanwenn]

On 2020/03/14 23:46:17, dak wrote:
> Why would we want to move away from GNU make as a build system?

The current build system is a per directory system, which is
fundamentally flawed. (See http://aegis.sourceforge.net/auug97.pdf).
This has several implications:

* we can't get enough parallelism in the doc build

* there are several underspecified dependencies (eg. if you change
something scripts/build/ , a build in mf/ will not pick up the change)

then there are problems with stepmake

* because each subdirectory has its own output directory  (eg. mf/out/
), a significant part of our build is involved with copying/symlinking
files so we don't have out-www/ in our HTML links.

* our build system relies heavily on GNU make magic. As a programming
language, GNU Make just isn't very good. It's not expressive, and it has
no typesystem. This makes it hard for people to work on the build
system.

* stepmake tried to be generic Make templating system (but did a bad job
at it). At the same time, the genericity is causing complexity

I have been experimenting with Ninja (https://ninja-build.org/), but
Ninja has a very restricted model. Make functions, wildcards, etc. are
not possible. In order to advance my experiments, I'm trying to clean up
the build so I can port more of the build over.

But even if we don't migrate to something else, cleaning up the build
makes it easier to maintain.

See https://github.com/hanwen/lilypond/tree/ninja if you want to try it
out.








Moving to something el

https://codereview.appspot.com/553700043/