3 ms·

>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 she

>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.

jstimpfle 9y ago
> 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-Function 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 do_your_thing_with(splitfiles("""$(MYMAKEMACRO)""")) 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?
- lolikoisuru 9y ago
  >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.

jstimpfle 9y ago

> 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-Function 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 do_your_thing_with(splitfiles("""$(MYMAKEMACRO)""")) 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?

lolikoisuru 9y ago
>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.