5 ms·

>Make has a fragile syntax that barely works for simple filenames It works perfectly fine with things other than space. >and it has a host of cryptic function

>Make has a fragile syntax that barely works for simple filenames It works perfectly fine with things other than space. >and it has a host of cryptic functions with difficult to understand semantics This is why the GNU Make has a fantastic manual, I suggest you check it out: https://gnu.org/s/make/manual https://gnu.org/s/make/manual >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.

jstimpfle 9y ago
> 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. > This is why the GNU Make has a fantastic manual, I suggest you check it out: https://gnu.org/s/make/manual https://gnu.org/s/make/manual 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.
- lolikoisuru 9y ago
  >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

> 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. > This is why the GNU Make has a fantastic manual, I suggest you check it out: https://gnu.org/s/make/manual https://gnu.org/s/make/manual 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.

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