7 ms·

>Replace "having start" with "having to start". And maybe replace "solve" with "remove", which might be a better fit here (I'm not a native speaker). The latte

>Replace "having start" with "having to start". And maybe replace "solve" with "remove", which might be a better fit here (I'm not a native speaker). The latter half of the sentence is still incomprehensible.

jstimpfle 9y ago
I thought it was perfectly understandable, but here is another way of putting it. By "going through a command-line interface" I mean that you have to start a new process, and hand over all state as command-line parameters (because it's a new process). This can be impractical and error-prone, especially if you add shell AND make syntax on top. From within a decent scripting language (e.g. Python) instead, you can simply use the convenient built-in data structures (e.g. list/tuple of str) as command-line parameters for subprocesses.
- lolikoisuru 9y ago
  >I mean that you have to start a new process, and hand over all state as command-line parameters (because it's a new process). Do you mean to the shell's command-line parameters or the compiler's? Either way whatever state you need you can also give as macro expansions. MACRO := whatever SHELL := /usr/bin/python .RECIPEPREFIX := > .ONESHELL: .PHONY: all .SILENT: all: >foo="$(MACRO)" >print("{}".format(foo)) >print("You can call yur compiler from python if you want. You could even write the build system from OP here if you wanted to") >This can be impractical and error-prone, especially if you add shell AND make syntax on top. Make syntax is just simple macro expansion. Shouldn't be too hard. And no one is forcing you to use a bourne-style shell. You can use Lua, Perl, Python, Javascript, whatever you want. >From within a decent scripting language (e.g. Python) instead You can use Python. >you can simply use the convenient built-in data structures (e.g. list/tuple of str) as command-line parameters for subprocesses. Then do that here. You don't need to reinvent everything just because you dislike one part of an existing solution. This kind of NIH is why there are so many sub par solutions for everything and nothing is compatible with each other.
  - jstimpfle 9y ago
    Macro expansion is not "simple". If anything it's simplistic. Make has a fragile syntax that barely works for simple filenames, and it has a host of cryptic functions with difficult to understand semantics. That it's what is installed on most Unix-style computers isn't an argument against trying to make different/better systems. The point of my post was to show that there isn't much to the fundamentals of Make. And to encourage finding out what is needed and how the weaknesses of Make can be avoided. Most people here seem to agree that the more advanced features of Make (i.e., what goes beyond POSIX Make) should not be used. Make is good for simple uses, since it's good at this: timestamp and DAG based process spawning. For advanced/specialized usage, it's terrible, much like it's the case with sh. I don't want to use it (at least not directly) for larger systems. See, I'm not a proponent of complexity and feature-laden systems at all. I despise C++, for example. But Make's syntax simply does not scale to larger systems. It does not offer solid enough abstractions to build your way up. Just like sh, which does not even have a usable list structure (there is only one list per function call). If what it does is enough for you, that's fine with me. It's not that I am unable to read the GNU Make docs (I have considered them more than once). Make just isn't good for more serious programming, as the proliferation of systems built on top (autoconf, CMake, ...) suggests. History has shown that macros do not scale. To my knowledge the only "macro languages" in widespread use for non-trivial things today are m4 and Tex, and frankly both are a pain to write things in. (While they do have their strengths if used expertly, for simple things). And while that is the case, Make is even less structured than those. Also there is no point in maintaining a plain Makefile if you are on other systems where Make isn't a first class citizen. I also need to generate Visual Studio files, for example. Also, you can set SHELL to another scripting language, but that defeats much of the point of using make in the first place. And again, you still need to spawn processes and transfer state through a fragile text interface. And most languages' syntaxes integrate even worse with Make's than sh does. How do I insert commas between words to generate python lists would be my first question, and frankly I do not want to know the answer. > This kind of NIH is why there are so many sub par solutions for everything and nothing is compatible with each other. It's not true that it's impossible to design a system that was better than Make. But before a system can be evaluated, one must decide what the system should be good at in the first place. I want a system with decidedly different strengths than Make. Having one syntax that sucks but is built-in and available everywhere is not a goal for me. And the "compatibility" argument is just not there, sorry. Yes, I require python, but that's it. I wrote a simple script that just runs and build. Nothing wrong with that.

jstimpfle 9y ago

I thought it was perfectly understandable, but here is another way of putting it. By "going through a command-line interface" I mean that you have to start a new process, and hand over all state as command-line parameters (because it's a new process). This can be impractical and error-prone, especially if you add shell AND make syntax on top. From within a decent scripting language (e.g. Python) instead, you can simply use the convenient built-in data structures (e.g. list/tuple of str) as command-line parameters for subprocesses.

lolikoisuru 9y ago
>I mean that you have to start a new process, and hand over all state as command-line parameters (because it's a new process). Do you mean to the shell's command-line parameters or the compiler's? Either way whatever state you need you can also give as macro expansions. MACRO := whatever SHELL := /usr/bin/python .RECIPEPREFIX := > .ONESHELL: .PHONY: all .SILENT: all: >foo="$(MACRO)" >print("{}".format(foo)) >print("You can call yur compiler from python if you want. You could even write the build system from OP here if you wanted to") >This can be impractical and error-prone, especially if you add shell AND make syntax on top. Make syntax is just simple macro expansion. Shouldn't be too hard. And no one is forcing you to use a bourne-style shell. You can use Lua, Perl, Python, Javascript, whatever you want. >From within a decent scripting language (e.g. Python) instead You can use Python. >you can simply use the convenient built-in data structures (e.g. list/tuple of str) as command-line parameters for subprocesses. Then do that here. You don't need to reinvent everything just because you dislike one part of an existing solution. This kind of NIH is why there are so many sub par solutions for everything and nothing is compatible with each other.
- jstimpfle 9y ago
  Macro expansion is not "simple". If anything it's simplistic. Make has a fragile syntax that barely works for simple filenames, and it has a host of cryptic functions with difficult to understand semantics. That it's what is installed on most Unix-style computers isn't an argument against trying to make different/better systems. The point of my post was to show that there isn't much to the fundamentals of Make. And to encourage finding out what is needed and how the weaknesses of Make can be avoided. Most people here seem to agree that the more advanced features of Make (i.e., what goes beyond POSIX Make) should not be used. Make is good for simple uses, since it's good at this: timestamp and DAG based process spawning. For advanced/specialized usage, it's terrible, much like it's the case with sh. I don't want to use it (at least not directly) for larger systems. See, I'm not a proponent of complexity and feature-laden systems at all. I despise C++, for example. But Make's syntax simply does not scale to larger systems. It does not offer solid enough abstractions to build your way up. Just like sh, which does not even have a usable list structure (there is only one list per function call). If what it does is enough for you, that's fine with me. It's not that I am unable to read the GNU Make docs (I have considered them more than once). Make just isn't good for more serious programming, as the proliferation of systems built on top (autoconf, CMake, ...) suggests. History has shown that macros do not scale. To my knowledge the only "macro languages" in widespread use for non-trivial things today are m4 and Tex, and frankly both are a pain to write things in. (While they do have their strengths if used expertly, for simple things). And while that is the case, Make is even less structured than those. Also there is no point in maintaining a plain Makefile if you are on other systems where Make isn't a first class citizen. I also need to generate Visual Studio files, for example. Also, you can set SHELL to another scripting language, but that defeats much of the point of using make in the first place. And again, you still need to spawn processes and transfer state through a fragile text interface. And most languages' syntaxes integrate even worse with Make's than sh does. How do I insert commas between words to generate python lists would be my first question, and frankly I do not want to know the answer. > This kind of NIH is why there are so many sub par solutions for everything and nothing is compatible with each other. It's not true that it's impossible to design a system that was better than Make. But before a system can be evaluated, one must decide what the system should be good at in the first place. I want a system with decidedly different strengths than Make. Having one syntax that sucks but is built-in and available everywhere is not a goal for me. And the "compatibility" argument is just not there, sorry. Yes, I require python, but that's it. I wrote a simple script that just runs and build. Nothing wrong with that.