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

[Han-Wen Nienhuys]

On Sun, Mar 15, 2020 at 5:04 PM <address@hidden> wrote:
>
> On 2020/03/15 14:39:06, hanwenn wrote:
> > On Sun, Mar 15, 2020 at 12:05 PM <mailto:address@hidden>
> wrote:
> > > On 2020/03/14 23:57:48, hanwenn wrote:
> > > > 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.
> > >
> > > 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 build.ninja file from a Python script
> > directly, without any attempt to make it generic. We'll see how far
> > that brings me.
>
> I did so now and ... does this mean you want to write yet another meta
> build system? That sounds horrible to maintain.

It doesn't have to be a *meta* build system, because it doesn't have
to cater to anything but LilyPond. That makes me confident that it
will be much simpler than any of the existing systems.

> > > What's the motivation to use Python for all of this?
> >
> > What's the motivation to use sh for all this?
>
> Let me explain with my background of porting to Python 3: It was a
> nightmare which leads me to the conclusion that Python scripts are not
> easy to maintain over an extended period of time. I recently read
> https://gregoryszorc.com/blog/2020/01/13/mercurial's-journey-to-and-reflections-on-python-3/
> and this very much confirms this point.
> sh instead is pretty much the same since decades and *very* portable.

I very much agree with you, but out of the existing language within
our tree (Perl, Python, Shell, C++, Make), it is the least worst
option. Make is too limited (see the mess that our makefiles are
today), Shell has all the problems of Make. We can't use C++ in the
build system, and Perl is a godawful mess of line-noise.

What do you suggest instead?

For all the code where I have a choice of language, I nowadays use Go,
and I'd be happy to do a (meta)build system in Go.

-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen