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

[jonas . hahnfeld]

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.

> > 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.

On 2020/03/15 15:10:05, wl_gnu.org wrote:
> Jonas, the rule is very simple: Use whatever you think is best.  A
> contributor invests time and has to make sure that the code works and
> is well-documented.  But why should we enforce a certain programming
> language (of the ones we already use, that is)?

Yes, and others might disagree with a particular choice. For build
scripts, I think it's the wrong language (see above).

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