5 ms·

It's still 100% relevant. I can only speak for FreeBSD, but this is a real pain when building from source (outside of FreeBSD Ports). https://www.freebsd.org/c

It's still 100% relevant. I can only speak for FreeBSD, but this is a real pain when building from source (outside of FreeBSD Ports). https://www.freebsd.org/cgi/man.cgi?make(1) https://www.freebsd.org/cgi/man.cgi?make(1)

nullifidian 7y ago
installing gnu make on FreeBSD is not hard. Other unixes such as AIX and Solaris are super obscure now, and gnu make also works there.
- rcthompson 7y ago
  Installing GNU Make is not the problem. It's knowing which Make to invoke. If you use GNUMakefile, it's unambiguous.
  - nullifidian 7y ago
    It's simple, you make gnu make the default one and the problem is solved.
    - codetrotter 7y ago
      You definitely do not want to make GNU Make the default on a system that ships with another implementation of Make, because then you break other builds. The solution, like the other people were saying, is to name the makefile as GNUmakefile if it is using GNU Make specific features.
      - nullifidian 7y ago
        >because then you break other builds. [citation needed] Gnu make is a superset of posix compatible make standard.(with very few exceptions) It shouldn't break. If it breaks, I think it's a bug, and the makefile should be altered into posix-compliant compatibility with gnu make.
        johnr2 7y ago
        >>because then you break other builds. >[citation needed] From OpenBSD make(1) manpage: "The handling of ‘.depend’ is a BSD extension."
        nullifidian 7y ago
        Well, using "BSD extension" in 2019 is a luxury.
        johnr2 7y ago
        > Well, using "BSD extension" in 2019 is a luxury. Considering it's the default on the OS I'm using to post this (OpenBSD) I'd regard it as fairly standard.
        codetrotter 7y ago
        The suggestion by the parent of my comment was to replace the system Make with GNU Make because others are using GNU Make specific features. On top of that you want to rewrite all of the Makefiles for other implementations of Make, that exist on systems where the implementation of Make that is included with the system is not GNU Make, so that the system still works after you've switched out the implementation of Make that came with the system with GNU Make. ... Why? Why should everyone else do a bunch of extra work just so that the projects using GNU Make can keep using GNU Make specific features, when literally all those people using those GNU Make features had to do was to rename their Makefile to GNUmakefile and it would keep working for them when they invoke GNU Make just the same way they did before and would not cause confusion for others?
        nullifidian 7y ago
        If you are talking about a bunch of BSD userland, probably the only place that uses BSD extensions and other gnu incompatible non-posix stuff, I think it's pretty easy to hardwire it to only build with BSD make variants. Who even builds it manually, and how often? The OPs comment was about software in general, and for software in general gnu make is more optimal as a default in 2019, that is unless you have to be standards-compliant.
  - asveikau 7y ago
    I find on bsd when I type make and it spews out many screenfulls of syntax errors before performing any work, then I type "gmake" as a next step. Not challenging.
    - zingermc 7y ago
      There are some GNU Makefiles that invoke `make` manually instead of `$(MAKE)`. On FreeBSD, where `make` is bmake, this is a pain in the ass.
      - asveikau 7y ago
        I agree that would be bad, but I haven't personally seen a lot of that. Increasing awareness of the $(MAKE) variable I guess would be the solution. Of course the "recursive make considered harmful" paper also articulates pretty well why such a usage may have its own problems. http://aegis.sourceforge.net/auug97.pdf http://aegis.sourceforge.net/auug97.pdf
  - makapuf 7y ago
    too bad the standard is not #!/usr/bin/gmake first line or something similar
codetrotter 7y ago
Adding to this, in cases where I needed to use non-portable Make features for projects that I would build for both Linux and FreeBSD, I always name the Makefile for GNU Make as GNUmakefile, and if I create a separate Makefile for the Make that FreeBSD ships with then I name that as BSDmakefile, which the Make that FreeBSD ships with will pick up by default when you run `make` just as GNU Make does for GNUmakefile. Unhappily though, I think there are further portability issues, namely that when I create my BSDmakefile I am not sure that all the features I use would work with the versions of Make that come with OpenBSD, NetBSD, etc. I mean, largely I don't do anything too crazy or fancy but the feeling is always there and I don't really have time/inclination to test every change with OpenBSD, NetBSD, etc since I don't normally use any of those other operating systems in the BSD family aside from FreeBSD which I do use. For the last few years I've been using C less though, as I prefer Rust anyway. And for the times when I do end up creating a makefile I now usually create only a GNUmakefile. Supporting only GNU Make feels a little bad but I think in most cases people will have it installed even on FreeBSD, and at least naming it as GNUmakefile like is being suggested and as I am doing, does not waste peoples time trying to run other implementations of Make with those projects even if it might annoy them to install GNU Make.
wruza 7y ago
I very quickly adopted a habit of typing gmake for downloaded sources. Can’t see any pain at all and why it is relevant. Make(1) is basically gnu make today and when it’s not, you’re aware of its alias. A suggestion for naming makefiles GNUmakefile is a funny try to borderline, but it is late for around two decades and cannot have effect beyond boring. In technical terms, it is easier to rename BSDmakefiles rather than millions of projects out there.
- saagarjha 7y ago
  > Make(1) is basically gnu make today It is not on a number of platforms that enjoy popular usage. > In technical terms, it is easier to rename BSDmakefiles rather than millions of projects out there. GNU is not the standard. Generally it's a superset of it; if so, then it should have the onus of the nonstandard name.
  - wruza 7y ago
    We have three choices with different success chances: - Rename non-gnu makefiles of a specific platform (tedious but possible), - Rename gnu makefiles in the entire internets (0% chance), - Continue insisting to no avail (requires no effort). >if so, then it should A wonderful world where such implications always work, but not where we live.

nullifidian 7y ago

installing gnu make on FreeBSD is not hard. Other unixes such as AIX and Solaris are super obscure now, and gnu make also works there.

rcthompson 7y ago
Installing GNU Make is not the problem. It's knowing which Make to invoke. If you use GNUMakefile, it's unambiguous.
- nullifidian 7y ago
  It's simple, you make gnu make the default one and the problem is solved.
  - codetrotter 7y ago
    You definitely do not want to make GNU Make the default on a system that ships with another implementation of Make, because then you break other builds. The solution, like the other people were saying, is to name the makefile as GNUmakefile if it is using GNU Make specific features.
    - nullifidian 7y ago
      >because then you break other builds. [citation needed] Gnu make is a superset of posix compatible make standard.(with very few exceptions) It shouldn't break. If it breaks, I think it's a bug, and the makefile should be altered into posix-compliant compatibility with gnu make.
      - johnr2 7y ago
        >>because then you break other builds. >[citation needed] From OpenBSD make(1) manpage: "The handling of ‘.depend’ is a BSD extension."
        nullifidian 7y ago
        Well, using "BSD extension" in 2019 is a luxury.
        johnr2 7y ago
        > Well, using "BSD extension" in 2019 is a luxury. Considering it's the default on the OS I'm using to post this (OpenBSD) I'd regard it as fairly standard.
      - codetrotter 7y ago
        The suggestion by the parent of my comment was to replace the system Make with GNU Make because others are using GNU Make specific features. On top of that you want to rewrite all of the Makefiles for other implementations of Make, that exist on systems where the implementation of Make that is included with the system is not GNU Make, so that the system still works after you've switched out the implementation of Make that came with the system with GNU Make. ... Why? Why should everyone else do a bunch of extra work just so that the projects using GNU Make can keep using GNU Make specific features, when literally all those people using those GNU Make features had to do was to rename their Makefile to GNUmakefile and it would keep working for them when they invoke GNU Make just the same way they did before and would not cause confusion for others?
        nullifidian 7y ago
        If you are talking about a bunch of BSD userland, probably the only place that uses BSD extensions and other gnu incompatible non-posix stuff, I think it's pretty easy to hardwire it to only build with BSD make variants. Who even builds it manually, and how often? The OPs comment was about software in general, and for software in general gnu make is more optimal as a default in 2019, that is unless you have to be standards-compliant.
- asveikau 7y ago
  I find on bsd when I type make and it spews out many screenfulls of syntax errors before performing any work, then I type "gmake" as a next step. Not challenging.
  - zingermc 7y ago
    There are some GNU Makefiles that invoke `make` manually instead of `$(MAKE)`. On FreeBSD, where `make` is bmake, this is a pain in the ass.
    - asveikau 7y ago
      I agree that would be bad, but I haven't personally seen a lot of that. Increasing awareness of the $(MAKE) variable I guess would be the solution. Of course the "recursive make considered harmful" paper also articulates pretty well why such a usage may have its own problems. http://aegis.sourceforge.net/auug97.pdf http://aegis.sourceforge.net/auug97.pdf
- makapuf 7y ago
  too bad the standard is not #!/usr/bin/gmake first line or something similar

codetrotter 7y ago

Adding to this, in cases where I needed to use non-portable Make features for projects that I would build for both Linux and FreeBSD, I always name the Makefile for GNU Make as GNUmakefile, and if I create a separate Makefile for the Make that FreeBSD ships with then I name that as BSDmakefile, which the Make that FreeBSD ships with will pick up by default when you run `make` just as GNU Make does for GNUmakefile. Unhappily though, I think there are further portability issues, namely that when I create my BSDmakefile I am not sure that all the features I use would work with the versions of Make that come with OpenBSD, NetBSD, etc. I mean, largely I don't do anything too crazy or fancy but the feeling is always there and I don't really have time/inclination to test every change with OpenBSD, NetBSD, etc since I don't normally use any of those other operating systems in the BSD family aside from FreeBSD which I do use. For the last few years I've been using C less though, as I prefer Rust anyway. And for the times when I do end up creating a makefile I now usually create only a GNUmakefile. Supporting only GNU Make feels a little bad but I think in most cases people will have it installed even on FreeBSD, and at least naming it as GNUmakefile like is being suggested and as I am doing, does not waste peoples time trying to run other implementations of Make with those projects even if it might annoy them to install GNU Make.

wruza 7y ago

I very quickly adopted a habit of typing gmake for downloaded sources. Can’t see any pain at all and why it is relevant. Make(1) is basically gnu make today and when it’s not, you’re aware of its alias. A suggestion for naming makefiles GNUmakefile is a funny try to borderline, but it is late for around two decades and cannot have effect beyond boring. In technical terms, it is easier to rename BSDmakefiles rather than millions of projects out there.

saagarjha 7y ago
> Make(1) is basically gnu make today It is not on a number of platforms that enjoy popular usage. > In technical terms, it is easier to rename BSDmakefiles rather than millions of projects out there. GNU is not the standard. Generally it's a superset of it; if so, then it should have the onus of the nonstandard name.
- wruza 7y ago
  We have three choices with different success chances: - Rename non-gnu makefiles of a specific platform (tedious but possible), - Rename gnu makefiles in the entire internets (0% chance), - Continue insisting to no avail (requires no effort). >if so, then it should A wonderful world where such implications always work, but not where we live.