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: David Kastrup
Subject: Re: scripts/build/scan-mf-deps: script to generate MF dependencies (issue 553700043 by address@hidden)
Date: Sun, 15 Mar 2020 20:32:09 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Han-Wen Nienhuys <address@hidden> writes:

> On Sun, Mar 15, 2020 at 5:03 PM David Kastrup <address@hidden> wrote:
>> Makefiles are an established technique well-known to most contributors.
>> Recursive python scripts for writing human-unreadable controlling files
>
> What recursive script are you talking about ?

It is you who stated the following:

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

So apparently you want to use Python for recursive scripting, or why
bring it up?

>> in some build system that is the current fad of the year incompatible
>> with anything else
>
> Are you talking about Ninja? You realize that it is the standard
> infrastructure of virtually all modern build systems, including
> Meson/CMake.

It is one backend of several for those, and the more common CMake
predates Ninja.

> The chrome browser is built with Ninja, as is the Android platform,

The Ninja website itself states "parts of Android".  It also states
"Where other build systems are high-level languages Ninja aims to be an
assembler." and "it is designed to have its input files generated by a
higher-level build system,".

So your Python scripts are intended to eventually constitute another
higher-level build system instead of reusing an existing one, with Ninja
operating at the assembler level?

This just screams like being slated to become a very person-bound
dependency in the form of an idiosyncratic build system designed from
scratch in essential parts, and eventually a liability.

The problems with Make you stated you wanted to address with that are
more problems with the _current_ Makefile architecture and dependency
setup rather than inherent with Make.  While a complete switch of tools
has the advantage of making it easier to abandon parts of the design
that are equal parts legacy and liability, the principal problems of
incomplete dependencies particularly cross-directory, incomplete job
control, and somewhat incrutable setup of what rules belong where in the
stepmake system are not an inherent problem of Make but of what we have
built around it.

-- 
David Kastrup



reply via email to

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