lilypond-devel
[Top][All Lists]
Advanced

[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 19:52:14 +0100

On Sun, Mar 15, 2020 at 7:14 PM <address@hidden> wrote:
> > On Sun, Mar 15, 2020 at 5:04 PM <mailto:address@hidden>
> wrote:
> > > 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.
>
> It's a (build) system that generates files for a build system. I'd call
> this "meta" but this is likely a matter of definition.

Python + Ninja seems like its a system with less surprises, and
therefore, better maintainability than autoconf + make.

> > 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?
>
> Not doing this at all.
> In cases like this, I begin to question the very fundamental
> assumptions. In this case: Do we really need to dynamically generate the
> dependencies if there's really no tool for it? My answer is "no" after
> seeing that the last change of 'include' statements was in 2013 (if you
> count a2f44bbf0e; otherwise maybe earlier). As such, how about just
> making them static? See https://codereview.appspot.com/555440062 to get
> the idea.

FWIW, at some point the dependency generation was part of
mf-to-table.py, which generated from the log file (using Python). I
don't know why it was moved to be a make macro.

If we think we're not going to change the mf files, why not just check
in the OTF files?

(tongue in cheek, but you get the idea).

In general leaving functionality intact leads to less discussion,
which lets me move faster.

In this case in particular, though, I think that as long as we're
building the fonts from mf using make, we should generate correct
dependencies. The build system is kind of a mess, but I think
hard-coding hardcoding dependencies is strictly worse.

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



reply via email to

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