9 ms·

You are not wrong, but if the world where not full with even worse build systems it'd be a bit saying I prefer to drink from puddles because I find them whereve

by patrec 6y ago

You are not wrong, but if the world where not full with even worse build systems it'd be a bit saying I prefer to drink from puddles because I find them wherever I go. Make is everywhere, but apart from UX issues such as the dumb syntax or the different flavors you'll encounter, the fundamental problem with it is that it just can't build things properly (the existence of make clean is the dead give away here). That's fine for trivial stuff, but for real work you really owe it to yourself (and society at large) to use a build system which can correctly build things. Some examples applying to the above: - if your paths have white space in them, you are generally fucked - if your change your Makefile, nothing will be rebuilt - if inkscape writes out a partial file because full disk and you fix the problem, the partial svg will no be rebuilt - if you install a new version of inkscape nothing will be rebuilt

dan00 6y ago
> - if your paths have white space in them, you are generally fucked Paths containing ':' are also fun. That make doesn't handle paths - and most likely other things - as a unit, but just substitutes their string representation into the makefile, is just asking for trouble.
- barumi 6y ago
  > Paths containing ':' are also fun. To be fair, anyone who uses reserved/special characters in file names is asking for trouble in pretty much any usage.
  - maple3142 6y ago
    But linux filename basically allows any byte sequence except EOF and /, so I think it is "make" fault to not being able to support it. Other proper build tools support it correctly.
    - patrec 6y ago
      Well, just because make is faulty, doesn't mean linux isn't too ;) Spaces -- ok. But there is absolutely no use case for allowing near arbitrary byte sequences in filenames, it causes no end of trouble, and it would have been trivial to fix in a non-disruptive manner ages ago (mount -o allowreallydumbfilenames, off by default).
    - barumi 6y ago
      > But linux filename basically allows any byte sequence except EOF and / (...) Could/should/would... Even though UNIX doesn't impose many restrictions on file names that doesn't mean it's in your best interests to use any weird character in them. I mean, do you honestly believe it's a good idea to have file names that are 256-characters long, have line breaks in their name, and have substrings such as "sudo rm -rf /"?
      - dan00 6y ago
        The point isn’t if it’s a good idea, but that a program shouldn’t misbehave.
      - maple3142 6y ago
        > I mean, do you honestly believe it's a good idea to have file names that are 256-characters long, have line breaks in their name, and have substrings such as "sudo rm -rf /"? Yes. It is usually some badly written programs or scripts choke on space, newline other things. BTW, I would like to impose a restriction that filename must be valid UTF-8 string instead of random bytes.
  - saagarjha 6y ago
    Still, it's not great to trip over them.
  - dan00 6y ago
    Having to be aware which character in a path is considered as special by which program, just doesn’t scale very well. It shouldn’t differentiate what an os and a program consider as a valid path.
chrismorgan 6y ago
> - if your paths have white space in them This is probably my second biggest complaint about Make. > - if you change your Makefile, nothing will be rebuilt Heh, there’s a common trick for that: just slap Makefile on the end of prerequisite lists. I’ve worked with more complex projects that extend this to versioning the makefile with a `build/.makefile-v${MAKEFILE_VERSION}` common prerequisite so that you can bump the version if the change is such that you’ll need to rebuild everything. > - if inkscape writes out a partial file because full disk and you fix the problem, the partial svg will no be rebuilt Or the more common form, you run a fallible program and it produces errors but still produced a file (e.g. if you used piping, `> $@` instead of a `--output=$@` command line argument that only creates the file after processing has succeeded). I think “build errored but produced a file” is probably my biggest complaint about Make. You can work around it in a few ways; `|| (touch --date=@0 $@; false)` is probably my favourite, which I used in https://chrismorgan.info/blog/make-and-git-diff-test-harness/ https://chrismorgan.info/blog/make-and-git-diff-test-harness.... > - if you install a new version of inkscape nothing will be rebuilt I’m curious: would Ninja rebuild on a new version of Inkscape? I’d be pleasantly surprised and view it much more favourably if it does. In the scope of Make, prerequisite satisfaction is all reckoned with timestamps, which is a thing I’m not always fond of, so you definitely can’t do this properly. I think the closest you could get is generating a file containing the versions of all your prerequisites, and arrange for it to only be updated when they’ve changed. Basically a slight variant of the MAKEFILE_VERSION trick discussed earlier, though definitely much more involved, especially if you want it to have one filename always rather than just being a hash of all the versions. And yes, all this is supporting your point that Make is not the best thing in this space, which I quite agree with. But for simple things I reckon it’s often still worth using despite this.
- codemac 6y ago
  > > - if your paths have white space in them > > This is probably my second biggest complaint about Make. If only more of the world used rc instead of bash, we'd be in a better place.
  - cassepipe 6y ago
    rc?
barumi 6y ago
> You are not wrong, but if the world where not full with even worse build systems it'd be a bit saying I prefer to drink from puddles because I find them wherever I go. That assertion is quite wrong. If you really want to go with that metaphor them the alternative to drinking from all the puddles you have readily available is to ignore them all and instead resort to waste time digging your own hole in the ground each and every single time you feel a little thirsty. Then, in the only practical and conceivable advantage you get from all the extra work is to allow you to enjoy a particular earthy flavour that in the end can't be objectively described as an improvement.
jdgiese 6y ago
> - if inkscape writes out a partial file because full disk and you fix the problem, the partial svg will no be rebuilt You can use the `.DELETE_ON_ERROR` phony target to solve this problem. You can read more about this in this short article: https://innolitics.com/articles/make-delete-on-error/ https://innolitics.com/articles/make-delete-on-error/

by patrec 6y ago

dan00 6y ago

> - if your paths have white space in them, you are generally fucked Paths containing ':' are also fun. That make doesn't handle paths - and most likely other things - as a unit, but just substitutes their string representation into the makefile, is just asking for trouble.

barumi 6y ago
> Paths containing ':' are also fun. To be fair, anyone who uses reserved/special characters in file names is asking for trouble in pretty much any usage.
- maple3142 6y ago
  But linux filename basically allows any byte sequence except EOF and /, so I think it is "make" fault to not being able to support it. Other proper build tools support it correctly.
  - patrec 6y ago
    Well, just because make is faulty, doesn't mean linux isn't too ;) Spaces -- ok. But there is absolutely no use case for allowing near arbitrary byte sequences in filenames, it causes no end of trouble, and it would have been trivial to fix in a non-disruptive manner ages ago (mount -o allowreallydumbfilenames, off by default).
  - barumi 6y ago
    > But linux filename basically allows any byte sequence except EOF and / (...) Could/should/would... Even though UNIX doesn't impose many restrictions on file names that doesn't mean it's in your best interests to use any weird character in them. I mean, do you honestly believe it's a good idea to have file names that are 256-characters long, have line breaks in their name, and have substrings such as "sudo rm -rf /"?
    - dan00 6y ago
      The point isn’t if it’s a good idea, but that a program shouldn’t misbehave.
    - maple3142 6y ago
      > I mean, do you honestly believe it's a good idea to have file names that are 256-characters long, have line breaks in their name, and have substrings such as "sudo rm -rf /"? Yes. It is usually some badly written programs or scripts choke on space, newline other things. BTW, I would like to impose a restriction that filename must be valid UTF-8 string instead of random bytes.
- saagarjha 6y ago
  Still, it's not great to trip over them.
- dan00 6y ago
  Having to be aware which character in a path is considered as special by which program, just doesn’t scale very well. It shouldn’t differentiate what an os and a program consider as a valid path.

chrismorgan 6y ago

> - if your paths have white space in them This is probably my second biggest complaint about Make. > - if you change your Makefile, nothing will be rebuilt Heh, there’s a common trick for that: just slap Makefile on the end of prerequisite lists. I’ve worked with more complex projects that extend this to versioning the makefile with a `build/.makefile-v${MAKEFILE_VERSION}` common prerequisite so that you can bump the version if the change is such that you’ll need to rebuild everything. > - if inkscape writes out a partial file because full disk and you fix the problem, the partial svg will no be rebuilt Or the more common form, you run a fallible program and it produces errors but still produced a file (e.g. if you used piping, `> $@` instead of a `--output=$@` command line argument that only creates the file after processing has succeeded). I think “build errored but produced a file” is probably my biggest complaint about Make. You can work around it in a few ways; `|| (touch --date=@0 $@; false)` is probably my favourite, which I used in https://chrismorgan.info/blog/make-and-git-diff-test-harness/ https://chrismorgan.info/blog/make-and-git-diff-test-harness.... > - if you install a new version of inkscape nothing will be rebuilt I’m curious: would Ninja rebuild on a new version of Inkscape? I’d be pleasantly surprised and view it much more favourably if it does. In the scope of Make, prerequisite satisfaction is all reckoned with timestamps, which is a thing I’m not always fond of, so you definitely can’t do this properly. I think the closest you could get is generating a file containing the versions of all your prerequisites, and arrange for it to only be updated when they’ve changed. Basically a slight variant of the MAKEFILE_VERSION trick discussed earlier, though definitely much more involved, especially if you want it to have one filename always rather than just being a hash of all the versions. And yes, all this is supporting your point that Make is not the best thing in this space, which I quite agree with. But for simple things I reckon it’s often still worth using despite this.

codemac 6y ago
> > - if your paths have white space in them > > This is probably my second biggest complaint about Make. If only more of the world used rc instead of bash, we'd be in a better place.
- cassepipe 6y ago
  rc?

barumi 6y ago

> You are not wrong, but if the world where not full with even worse build systems it'd be a bit saying I prefer to drink from puddles because I find them wherever I go. That assertion is quite wrong. If you really want to go with that metaphor them the alternative to drinking from all the puddles you have readily available is to ignore them all and instead resort to waste time digging your own hole in the ground each and every single time you feel a little thirsty. Then, in the only practical and conceivable advantage you get from all the extra work is to allow you to enjoy a particular earthy flavour that in the end can't be objectively described as an improvement.

jdgiese 6y ago

> - if inkscape writes out a partial file because full disk and you fix the problem, the partial svg will no be rebuilt You can use the `.DELETE_ON_ERROR` phony target to solve this problem. You can read more about this in this short article: https://innolitics.com/articles/make-delete-on-error/ https://innolitics.com/articles/make-delete-on-error/