5 ms·

If your makefiles use gnu-isms (which is a valid choice) then I would lean towards using GNUmakefile and have Makefile call gmake - and don’t forget to use $(MA

by mcbain 8y ago

If your makefiles use gnu-isms (which is a valid choice) then I would lean towards using GNUmakefile and have Makefile call gmake - and don’t forget to use $(MAKE) for any recursion. This is less fragile and requires less dependence on replacing make in the $PATH.

ComputerGuru 8y ago
Glad I’m not the only one: https://github.com/neosmart/gmake-proxy https://github.com/neosmart/gmake-proxy All maintained and ready to go.
rwmj 8y ago
Could do all that, but FreeBSD could also have GNU make as the standard "make". I know there's some "license purity" reason why they don't want to do that, but don't expect everyone else to work around your self-imposed problem.
- minusf 8y ago
  isn't make older than gmake? it is normally gnu that adds extensions not compatible with the rest of the Unix world. making people believe sh == bash, make == gmake, m4 == gm4, and the list goes on for everything they touch.
  - bewo001 8y ago
    Every Unix used to have its own implementation of those standard tools. They were often quite buggy and outdated (eg the C compiler that came with SunOS and Solaris in the mid 1990's only supported K&R syntax). When installing Solaris, Sinix, AIX etc, you'd typically install the GNU tools immediately. I understand the FreeBSD folks' frustration, though.
  - shlomifish 8y ago
    To be frank, many of the GNU extensions are very useful. BSD tools have their own extensions over POSIX as well. Anyway, GNU software is FOSS and tends to be portable and so you can create something like GNU/FreeBSD or GNU/OpenBSD or whatever (Debian did it in the past). Naturally, the GPL/LGPL/etc. may not be "free" enough for the tastes of the BSD devs, but this is getting into politics.
  - lmz 8y ago
    But BSD make has extensions too. They're just different extensions.
  - kps 8y ago
    “Embrace, extend, extinguish.”
- simias 8y ago
  GNU make is ported to FreeBSD and very frequently used to build ports that use GNU-isms in their Makefiles. It's a non-issue really.
  - wolfgke 8y ago
    > GNU make is ported to FreeBSD and very frequently used to build ports that use GNU-isms in their Makefiles. It's a non-issue really. At least the OpenBSD developers hated the Linuxisms so much that they made a song "Aquarela do Linux!" to name and shame this: > https://www.openbsd.org/lyrics.html#52 https://www.openbsd.org/lyrics.html#52
- jlg23 8y ago
  No, GNU devs should understand Unix beyond the GNU ecosystem. I'd be retired on my private planet if I had gotten a dime each time I ported Linux software (mostly the build system) to work on non-linux unixoid operating system. To be fair: Nothing in GNUiverse teaches you interoperability; I too learned it the hard way when switching from Linux to BSD.
  - rwmj 8y ago
    GNU is literally a platform. If you want to run the software on another platform (particularly one which is not as widely used as GNU) then you have to port the software.
    - dzamo_norton 8y ago
      Or you have to write portable software.
ainar-g 8y ago
A genuine question. What is a highly needed feature that GNU Make have that you can't do with POSIX Make? My personal pet peeve with POSIX Make is that you can't export an environment variable for one target only without calling $(MAKE)[1]. [1] https://stackoverflow.com/q/52427295/1892060 https://stackoverflow.com/q/52427295/1892060.
- nrclark 8y ago
  GNU Make's got tons of features that aren't in POSIX Make (so does BSD Make). I use GNU-specific Makefile features all the time - here's a list of some of the cool features: - Built-in functions (see https://www.gnu.org/software/make/manual/html_node/Functions.html for a list) - User-supplied functions - Much better pattern substitution - Ways to tell Make that some files can be skipped in certain cases (.INTERMEDIATE and .SECONDARY modifiers) - Ways to adjust Make's behavior (SECONDEXPANSION, DELETE_ON_ERROR, ONESHELL) As a software packager, I'd advocate for autotools or CMake over a raw Makefile every time (assuming your project is a library or some binaries). But with that said, I use GNU Make all the time for "glue automation" - like if I had a folder full of files that needed some processing, I'd probably write a Makefile instead of a shell script. I also use top-level Makefiles on projects that have their own build systems, so that I don't need to remember how they work every time. People use shell scripts for that stuff too, but Make is better IMO.
  - richardwhiuk 8y ago
    I'm curious - what does autotools / CMake actually give you? Personally, I find they generate awful Makefiles which are slow and aren't debuggable.
    - megous 8y ago
      Cheap portabiltiy. Easy use by packagers. It annoys me quite a bit when someone decides not to use autotools or meson, or other standard build tools. I have a build system set up to build static packages for several architectures, and most of my packages are described like this: name=some ver=123 url=https://where-to-get/some-$ver.tar.gz build() { autotools_build --some-option } And it does the right thing for all packages that use autotools. If you roll out your own Makefile, I have to figure out how to build the targets, how to install them, whether you use DESTDIR, whether you respect cross-compile options, how to build static library, how to configure your package... and code all this by hand to build() function. The same goes for my custom Arch Linux packages. Make the packagers job easy and just don't roll your own if you want your package to be distributed widely.

by mcbain 8y ago

ComputerGuru 8y ago

Glad I’m not the only one: https://github.com/neosmart/gmake-proxy https://github.com/neosmart/gmake-proxy All maintained and ready to go.

rwmj 8y ago

Could do all that, but FreeBSD could also have GNU make as the standard "make". I know there's some "license purity" reason why they don't want to do that, but don't expect everyone else to work around your self-imposed problem.

minusf 8y ago
isn't make older than gmake? it is normally gnu that adds extensions not compatible with the rest of the Unix world. making people believe sh == bash, make == gmake, m4 == gm4, and the list goes on for everything they touch.
- bewo001 8y ago
  Every Unix used to have its own implementation of those standard tools. They were often quite buggy and outdated (eg the C compiler that came with SunOS and Solaris in the mid 1990's only supported K&R syntax). When installing Solaris, Sinix, AIX etc, you'd typically install the GNU tools immediately. I understand the FreeBSD folks' frustration, though.
- shlomifish 8y ago
  To be frank, many of the GNU extensions are very useful. BSD tools have their own extensions over POSIX as well. Anyway, GNU software is FOSS and tends to be portable and so you can create something like GNU/FreeBSD or GNU/OpenBSD or whatever (Debian did it in the past). Naturally, the GPL/LGPL/etc. may not be "free" enough for the tastes of the BSD devs, but this is getting into politics.
- lmz 8y ago
  But BSD make has extensions too. They're just different extensions.
- kps 8y ago
  “Embrace, extend, extinguish.”
simias 8y ago
GNU make is ported to FreeBSD and very frequently used to build ports that use GNU-isms in their Makefiles. It's a non-issue really.
- wolfgke 8y ago
  > GNU make is ported to FreeBSD and very frequently used to build ports that use GNU-isms in their Makefiles. It's a non-issue really. At least the OpenBSD developers hated the Linuxisms so much that they made a song "Aquarela do Linux!" to name and shame this: > https://www.openbsd.org/lyrics.html#52 https://www.openbsd.org/lyrics.html#52
jlg23 8y ago
No, GNU devs should understand Unix beyond the GNU ecosystem. I'd be retired on my private planet if I had gotten a dime each time I ported Linux software (mostly the build system) to work on non-linux unixoid operating system. To be fair: Nothing in GNUiverse teaches you interoperability; I too learned it the hard way when switching from Linux to BSD.
- rwmj 8y ago
  GNU is literally a platform. If you want to run the software on another platform (particularly one which is not as widely used as GNU) then you have to port the software.
  - dzamo_norton 8y ago
    Or you have to write portable software.

ainar-g 8y ago

A genuine question. What is a highly needed feature that GNU Make have that you can't do with POSIX Make? My personal pet peeve with POSIX Make is that you can't export an environment variable for one target only without calling $(MAKE)[1]. [1] https://stackoverflow.com/q/52427295/1892060 https://stackoverflow.com/q/52427295/1892060.

nrclark 8y ago
GNU Make's got tons of features that aren't in POSIX Make (so does BSD Make). I use GNU-specific Makefile features all the time - here's a list of some of the cool features: - Built-in functions (see https://www.gnu.org/software/make/manual/html_node/Functions.html for a list) - User-supplied functions - Much better pattern substitution - Ways to tell Make that some files can be skipped in certain cases (.INTERMEDIATE and .SECONDARY modifiers) - Ways to adjust Make's behavior (SECONDEXPANSION, DELETE_ON_ERROR, ONESHELL) As a software packager, I'd advocate for autotools or CMake over a raw Makefile every time (assuming your project is a library or some binaries). But with that said, I use GNU Make all the time for "glue automation" - like if I had a folder full of files that needed some processing, I'd probably write a Makefile instead of a shell script. I also use top-level Makefiles on projects that have their own build systems, so that I don't need to remember how they work every time. People use shell scripts for that stuff too, but Make is better IMO.
- richardwhiuk 8y ago
  I'm curious - what does autotools / CMake actually give you? Personally, I find they generate awful Makefiles which are slow and aren't debuggable.
  - megous 8y ago
    Cheap portabiltiy. Easy use by packagers. It annoys me quite a bit when someone decides not to use autotools or meson, or other standard build tools. I have a build system set up to build static packages for several architectures, and most of my packages are described like this: name=some ver=123 url=https://where-to-get/some-$ver.tar.gz build() { autotools_build --some-option } And it does the right thing for all packages that use autotools. If you roll out your own Makefile, I have to figure out how to build the targets, how to install them, whether you use DESTDIR, whether you respect cross-compile options, how to build static library, how to configure your package... and code all this by hand to build() function. The same goes for my custom Arch Linux packages. Make the packagers job easy and just don't roll your own if you want your package to be distributed widely.