[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: scripts/build/scan-mf-deps: script to generate MF dependencies (issu

From: Han-Wen Nienhuys
Subject: Re: scripts/build/scan-mf-deps: script to generate MF dependencies (issue 553700043 by address@hidden)
Date: Sun, 15 Mar 2020 15:38:54 +0100

On Sun, Mar 15, 2020 at 12:05 PM <address@hidden> wrote:
> On 2020/03/14 23:57:48, hanwenn wrote:
> > I have been experimenting with Ninja (, 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.
> From the website: "it [Ninja] is designed to have its input files
> generated by a higher-level build system". And that's to be taken
> literally, the syntax is so low-level that it's no fun to read it, let
> alone write. So big NACK from me for switching to Ninja.

Have you looked at the code I wrote?   I know about Ninja, and in fact
I personally know its creator.

Using Ninja means generating a Ninja file. I looked for a bit at CMake
and Meson, but I'm not convinced they'll be a win; for one I'd have to
learn yet another poorly conceived and limited language. The LilyPond
build is highly custom (metafont, lilypond-book, texi2html), so it's
also not obvious that either they'll bring much to the table.

So I'm simply writing the file from a Python script
directly, without any attempt to make it generic. We'll see how far
that brings me.

> Both Meson and CMake are able to generate files for Ninja, but Meson is
> pretty new and I'm not sure yet whether it will become one of those
> projects that goes away after a few years (see Scons). CMake would
> certainly work, but has its own problems and corner cases. In sum we
> should definitely cleanup the current build system and see where it gets
> us.
> What I'm not really happy with is replacing all of this with custom
> Python scripts, however small they are. Skimming over,
> that looks totally doable in around half the lines with a sh script.
> What's the motivation to use Python for all of this?

What's the motivation to use sh for all this?

You can certainly make it shorter with shell, but will it be
significantly simpler, easier to understand or easier to maintain?

I decided for Python in this case, because recursion seems like
something I don't want to do in a sh script.

Han-Wen Nienhuys - address@hidden -

reply via email to

[Prev in Thread] Current Thread [Next in Thread]