Han-Wen Nienhuys <hanw...@gmail.com> writes: > On Sun, Mar 15, 2020 at 5:03 PM David Kastrup <d...@gnu.org> 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
