6 ms·

Terrible clickbaity title that he walks back throughout the entire post - "this is not dogma". There are a couple of valid remedial notes in here (like using f

Terrible clickbaity title that he walks back throughout the entire post - "this is not dogma". There are a couple of valid remedial notes in here (like using files as targets) but the part about changing the default shell and inserting hacks that allow you to use spaces will just baffle anyone else and probably make your Makefiles non-portable (eg macs don't have a recent bash).

lloeki 7y ago
> macs don't have a recent bash Macs don't have GNU make 4, only 3.81, so it's outright not portable with that > thingie.
- alwillis 7y ago
  Use Homebrew [1] to install the most current versions of bash and make. By default, it’s installed as gmake to not conflict with the existing make 3.81. [1]: https://brew.sh/ https://brew.sh/
  - lloeki 7y ago
    Sometimes you're not in a position to know, suggest, nor decide if people are using such a package manager (may it be Homebrew, MacPorts, ArchMac...) They may type make out of habit. This introduces a significant dependency, which makes people less inclined to use your stuff. It all depends on the use case, but in some situations a cop out such as "just use Homebrew" is actively user hostile due to the amount of human friction it generates. As it turns out, I've written bucketloads of portable (GNU and non-GNU) makefiles and never needed a post v3 feature.
- blattimwind 7y ago
  > Macs don't have GNU make 4, only 3.81 Released April 1st, 2004.
  - Tomte 7y ago
    Without looking it up: make probably had a license change (to GPLv3?) between those versions. That's usually the reason why Macs have outdated tools from Linux land.
    - blattimwind 7y ago
      Yes, 3.81 is GPLv2 or later, 3.82 is GPLv3.
      - panpanna 7y ago
        But why would GPLv3 be a problem for Apple in this case? Is this a more political move?
        detaro 7y ago
        They appear to have a general rule of never using GPLv3, even if it would be fine for some tools. (It'd be problematic for things that could also be a part of iOS, or components they'd lock down with unavoidable SIP-like mechanisms, option they likely want to keep open for parts of the system)
        panpanna 7y ago
        This is a horrible decision and is bad for developers everywhere.
        saagarjha 7y ago
        Apple is actively ripping out software licensed under earlier versions of GPL as well, as they're now horribly out of date.
        anoncake 7y ago
        It's a terrible decision for developers everywhere but what about Apple's profits?
zeveb 7y ago
> probably make your Makefiles non-portable (eg macs don't have a recent bash). Is there any point in supporting a platform which hasn't updated its major version of Make in over 15 years?
- microtherion 7y ago
  Picking the platforms you support by which version of make they ship is a rather odd way of doing business.
OskarS 7y ago
The "replace the tab with magic character" thing particularly baffling. I agree that it was probably a dumb idea in the beginning for make to force you to use a literal tab character, but using these kinds of hacks is a terrible idea. It will just make it harder to read makefiles for normal people and it will make them less portable. Every sensible programming editor knows that make is particular about spaces and tabs and will make sure that it uses tabs to indent the recipes, so it's not an issue any more. If anything, using some other character will make it more confusing, because I'm guessing most editors will indent/syntax highlight it incorrectly. It's not dissimilar from early C programmers who wanted C to be more like Pascal and put things like this in headers: #define BEGIN { #define END } and then never used curly braces. NO! DON'T DO IT!
- primis 7y ago
  Well now I have to try it
- panpanna 7y ago
  I really don't understand his justification for such a significant modification: > Make leans heavily on the shell, and in the shell spaces matter. Hence, the default behavior in Make of using tabs forces you to mix tabs and spaces, and that leads to readability issues. I agree with you in that replacing TAB with > makes things much less readable.
  - a-nikolaev 7y ago
    Yes, his justification is nonsense. 1) The original creator of Make plainly said that his original choice of tabs over spaces was accidental, and honestly a mistake. He just learned about (at the time) new tools lex and yacc for writing parsers and chose TAB as a line prefix for shell commands. Not much thought given really. 2) Tab in the very beginning of the line determines that the rest of the line is a command. However, the rest of that line goes into shell pretty much verbatim (modulo a few substitutions). Because of that, you may have tabs in the middle of that line, no problem, and they will be passed into the shell to execute! 3) To my knowledge, shells treat '\t' and ' ' the same way as whitespace. If anyone knows such differences, please let me know tho, I will correct myself. On the other hand, ">" is an important shell operator.
gnulinux 7y ago
When people write software, they don't need to target any and all platforms that can possibly operate on this software as input. If you want to only target GNU, that is perfectly fine. Just name your file `GNUmakefile` or put a comment at the header or in `README` to indicate you only support GNU.
KindOne 7y ago
>macs don't have a recent bash macOS Catalina now uses zsh.
- alwillis 7y ago
  The default for new accounts in Catalina is zsh but if you upgrade, you'll still have bash: https://support.apple.com/en-us/HT208050 https://support.apple.com/en-us/HT208050

lloeki 7y ago

> macs don't have a recent bash Macs don't have GNU make 4, only 3.81, so it's outright not portable with that > thingie.

alwillis 7y ago
Use Homebrew [1] to install the most current versions of bash and make. By default, it’s installed as gmake to not conflict with the existing make 3.81. [1]: https://brew.sh/ https://brew.sh/
- lloeki 7y ago
  Sometimes you're not in a position to know, suggest, nor decide if people are using such a package manager (may it be Homebrew, MacPorts, ArchMac...) They may type make out of habit. This introduces a significant dependency, which makes people less inclined to use your stuff. It all depends on the use case, but in some situations a cop out such as "just use Homebrew" is actively user hostile due to the amount of human friction it generates. As it turns out, I've written bucketloads of portable (GNU and non-GNU) makefiles and never needed a post v3 feature.
blattimwind 7y ago
> Macs don't have GNU make 4, only 3.81 Released April 1st, 2004.
- Tomte 7y ago
  Without looking it up: make probably had a license change (to GPLv3?) between those versions. That's usually the reason why Macs have outdated tools from Linux land.
  - blattimwind 7y ago
    Yes, 3.81 is GPLv2 or later, 3.82 is GPLv3.
    - panpanna 7y ago
      But why would GPLv3 be a problem for Apple in this case? Is this a more political move?
      - detaro 7y ago
        They appear to have a general rule of never using GPLv3, even if it would be fine for some tools. (It'd be problematic for things that could also be a part of iOS, or components they'd lock down with unavoidable SIP-like mechanisms, option they likely want to keep open for parts of the system)
        panpanna 7y ago
        This is a horrible decision and is bad for developers everywhere.
        saagarjha 7y ago
        Apple is actively ripping out software licensed under earlier versions of GPL as well, as they're now horribly out of date.
        anoncake 7y ago
        It's a terrible decision for developers everywhere but what about Apple's profits?

zeveb 7y ago

> probably make your Makefiles non-portable (eg macs don't have a recent bash). Is there any point in supporting a platform which hasn't updated its major version of Make in over 15 years?

microtherion 7y ago
Picking the platforms you support by which version of make they ship is a rather odd way of doing business.

OskarS 7y ago

The "replace the tab with magic character" thing particularly baffling. I agree that it was probably a dumb idea in the beginning for make to force you to use a literal tab character, but using these kinds of hacks is a terrible idea. It will just make it harder to read makefiles for normal people and it will make them less portable. Every sensible programming editor knows that make is particular about spaces and tabs and will make sure that it uses tabs to indent the recipes, so it's not an issue any more. If anything, using some other character will make it more confusing, because I'm guessing most editors will indent/syntax highlight it incorrectly. It's not dissimilar from early C programmers who wanted C to be more like Pascal and put things like this in headers: #define BEGIN { #define END } and then never used curly braces. NO! DON'T DO IT!

primis 7y ago
Well now I have to try it
panpanna 7y ago
I really don't understand his justification for such a significant modification: > Make leans heavily on the shell, and in the shell spaces matter. Hence, the default behavior in Make of using tabs forces you to mix tabs and spaces, and that leads to readability issues. I agree with you in that replacing TAB with > makes things much less readable.
- a-nikolaev 7y ago
  Yes, his justification is nonsense. 1) The original creator of Make plainly said that his original choice of tabs over spaces was accidental, and honestly a mistake. He just learned about (at the time) new tools lex and yacc for writing parsers and chose TAB as a line prefix for shell commands. Not much thought given really. 2) Tab in the very beginning of the line determines that the rest of the line is a command. However, the rest of that line goes into shell pretty much verbatim (modulo a few substitutions). Because of that, you may have tabs in the middle of that line, no problem, and they will be passed into the shell to execute! 3) To my knowledge, shells treat '\t' and ' ' the same way as whitespace. If anyone knows such differences, please let me know tho, I will correct myself. On the other hand, ">" is an important shell operator.

gnulinux 7y ago

When people write software, they don't need to target any and all platforms that can possibly operate on this software as input. If you want to only target GNU, that is perfectly fine. Just name your file `GNUmakefile` or put a comment at the header or in `README` to indicate you only support GNU.

KindOne 7y ago

>macs don't have a recent bash macOS Catalina now uses zsh.

alwillis 7y ago
The default for new accounts in Catalina is zsh but if you upgrade, you'll still have bash: https://support.apple.com/en-us/HT208050 https://support.apple.com/en-us/HT208050