To make things clear, I didn't start or even participate in anything. You posted https://news.ycombinator.com/item?id=16543557 which I considered inappropriate, so I complained in a comment to that. As a result you replied in a way that missed any understanding and respect - instead you called my note "ad hominem" which wasn't the case at all, and harshly critized me for writing in an unintelligible way (I accidentally left out one word in a sentence, sorry for that). This comment was later deleted. I didn't do anything apart from complaining about your behaviour once.
Again, your behaviour is extremely disrespectful. Please reconsider the way you treat people here.
You never specified what about it is inappropriate. Your complaints about the language amounted at most to a pathetic ad hominem.
>As a result you replied in a way that missed any understanding and respect
There was nothing to understand as you had not communicated anything but the fact you found it somehow offensive. As the comment contains nothing offensive you need to be more specific. Since you didn't do that it comes of just as a dismissive personal attack.
>and harshly critized me for writing in an unintelligible way
This is because the sentence was unintelligible even when I'd asked multiple people to try to interpret it. This is not harsh criticism, it's just a statement of a fact.
>(I accidentally left out one word in a sentence, sorry for that)
The lack of that word made the sentence completely nonsensical. Why are you whining to me about not understanding it? And it seems you never fixed the sentence so it's still just as unintelligible.
>Changing SHELL does not solve the inconvenience of having start a new process and having to go through a command-line interface each time.
> Since you didn't do that it comes of just as a dismissive personal attack.
I think (from the earlier comment):
> Also changing the language for recipes is trivial and painfully obvious. If you can't do something as simple as `SHELL := /your/own/interpreter' then why do you think you are qualified to make a build system?
is quite an obvious personal attack, and it got deservedly flagged multiple times. I'm sure you're able to find this yourself from two little paragraphs. No need to act as if you couldn't. And even if you couldn't, no need to be extremely offensive and start name-calling.
> This is because the sentence was unintelligible even when I'd asked multiple people to try to interpret it. This is not harsh criticism, it's just a statement of a fact.
Of course it was harsh criticism for an oversight that just happens. The comment is no longer there, but you chose a completely inappropriate and aggressive tone.
> What does this mean?
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).
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.
>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.
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.
>That it's what is installed on most Unix-style computers isn't an argument against trying to make different/better systems.
You aren't making a better system though. You're making a worse, less flexible, less understood, system that no one can hire person to work for and that won't be useful at any workplace. If you really wanted to improve over make you'd be making a general purpose tool that isn't targeting any specific project or language.
Alas, this has jack shit to do with the comment you're replying to. Let's deal with the issues we've been talking about before shifting the goalpost.
>Also, you can set SHELL to another scripting language, but that defeats much of the point of using make in the first place.
It still gives you a standard interface that packagers and users would expect for build software and you don't have to rewrite your DAG every time by hand.
>And again, you still need to spawn processes and transfer state through a fragile text interface.
You break the task into multiple parts so you hopefully don't have to run it all every time.
Text files aren't really any more fragile than any other way to tranfer the state, just write a json or whatever format you like.
>And most languages' syntaxes integrate even worse with Make's than sh does.
What integration do you want that you had in your silly hand written one?
>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.
You can either construct a macro to do this or you can just give the data space delimited to python and change the spaces to commas there. Surely you know how to do it with python so why are you insisting on doing it with make?
>It's not true that it's impossible to design a system that was better than Make.
Of course it's possible. Too bad no one has actually attempted it.
>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.
You also require your own library. Most people probably don't have this installed. Also if you wrote this at a company and left then they'd have a half-baked build system and they cannot hire anyone that's familiar with it.
> It works perfectly fine with things other than space.
Cool, sounds like a really robust idea. Let's try some dollars or semicolons, then. I'm sure the next shell will be happy. (I don't even think that this is Make's biggest weakness. I can usually get along with that, as long as I get to choose the filenames and don't need any fancy strings otherwise. It's just a testament to what a poor programming model macros are).
> Text files aren't really any more fragile than any other way to tranfer the state
It's not about plain text files for transferring "state" (e.g. a list of fixed strings), which work fine for many cases and do have considerable advantages. This is about combining a cryptic shell language with a lousy build system macro syntax and semantics.
As I wrote many times, I do actually know Make and have read much of the manual. Can't you believe me?
> It still gives you a standard interface that packagers and users would expect for build software
Believe me, packagers are indeed able to run a python script as opposed to only a make script. (Yes, if my intent was to have a software packaged by independent maintainers, I should add a "clean" routine as well. And offer some knobs for compiler flags - but this is already veering into fragile land, since the developer can't know what unexpected compiler options package maintainers will come up with).
> What integration do you want that you had in your silly hand written one?
Now I can't parse this sentence, but I sense that it's not a polite one.
> You can either construct a macro to do this or you can just give the data space delimited to python and change the spaces to commas there.
Oh, come on. I do not want to put in so much work (it's not a one-time thing - you have to do that every time you transfer a list) for such a poor, fragile result.
> Surely you know how to do it with python so why are you insisting on doing it with make?
I do not want to mess with Make at all. This should not be news.
> You also require your own library.
You can easily replace that with csv or json (both will be more robust than Make), or just put the data as literals into the python script, as I stated. My script is not intended as a finished thing for other people to use. This should not be news, either.
>This is about combining a cryptic shell language with a lousy build system macro syntax and semantics.
Get over the shell part. You don't have to use Unix shells.
>As I wrote many times, I do actually know Make and have read much of the manual. Can't you believe me?
If you think the macro names are somhow cryptic, no I can't believe you. There are only a few of them to remember.
>Now I can't parse this sentence, but I sense that it's not a polite one.
You were complaining that languages other than sh integrate with Make worse than sh does. What integration do you need. The integration with sh is pretty much limited to some predefined macros such as $(CP) and $(RM).
>Oh, come on. I do not want to put in so much work (it's not a one-time thing - you have to do that every time you transfer a list) for such a poor, fragile result.
Then define a function to do it. Surely you know how to do that as a mighty python programmer, right?
>I do not want to mess with Make at all. This should not be news.
Your complaints about make make it seem like you think that when using make you have to do everything with it and shell. If you don't want to mess with make then mess with python.
> Get over the shell part. You don't have to use Unix shells.
I HAVE HEARD YOU. You've said that countless times. It doesn't change anything. There's the fundamental problem that the shell statement is a single string. You combine strings with Make to form a single string (it's a form of templating, recognizing some custom sequences), and then rely on a shell on the other end to parse it to the correct list/structure of tokens. The same fragile approach has lead to many, many SQL injection vulnerabilities (or simply fragilities) in the past. It's fundamentally not a solid approach. And there is no way to fix that.
There's a reason I haven't seen a usage of a Makefile using a different shell than sh in the wild. sh is the one language whose super minimal syntax plays best with that cheap sort of templating. It works typically, but it's a fragile construction that is relying on suitable inputs.
> If you think the macro names are somhow cryptic, no I can't believe you. There are only a few of them to remember.
It's not about the few named built-in functions. It's about the weird macro expansion model that does not even have a solid list data structure, and about the many cryptic non-identifier shorthands. And about the total lack of the slightest support for creating solid building blocks. A list structure and a way to define functions and I would be almost happy. But it's not there, and I'm not going to mess with this: https://www.gnu.org/software/make/manual/make.html#Call-Func... . And it's not even portable.
> The integration
By integration I meant the interplay that you get by overlaying two syntaxes (that of the shell, whatever it may be, and that of Make splicing things in). Mixing syntaxes has been a bad idea in the past, and always will be.
> Then define a function to do it. Surely you know how to do that as a mighty python programmer, right?
So I'm supposed to define the function with each invocation? Or define a special shell that pre-defines the function? And even then each line will look something like
And it will still be fragile. I simply don't think this is a good idea.
> Your complaints about make make it seem like you think that when using make you have to do everything with it and shell. If you don't want to mess with make then mess with python.
No, for the last time. I get what you say (I'm not dumb) and I don't think it's a good idea. At all. If you want to continue tinkering with macros, let's simply agree to disagree. Ok?
>So I'm supposed to define the function with each invocation?
Geez if only programming language designers had come up with a way to bring code from other files. They could call it "include" or something like that. But that's just some crazy talk of course.
Bitch please. You're the one who started with those.