5 ms·

Differences in GNU/BSD sed is hardly a bug in Make.

dspillett 4y ago
No, correct. But it is a good example of something that you might expect to be more standard than it is between platforms, because of its age and relative ubiquity, where the differences get highlighted when trying to create (not just with make but other tools too) a consistent build process for a project.
- czx4f4bd 4y ago
  Yeah, variance between different system utilities is one of the biggest underrated perils of shell scripting. For a long time, I worked on a team that mostly used Macs to administer Linux servers, which led to some confusing issues when people tested certain commands locally and then tried to use them on a server. It would be nice if shellcheck had checks to detect common BSD/GNU incompatibilities and warn about them so you don't have to catch them in the moment.
  - hulitu 4y ago
    I think that if one aims for compatibility , then it shall use POSIX.
arp242 4y ago
It wasn't claimed to be a bug.
SAI_Peregrinus 4y ago
But it is a bug in your Makefile to assume a particular version of a tool (or path to a tool, etc) without first checking (or otherwise forcing the correct thing to be used). For forcing the existence of tools, you can start your Makefile by setting up $PATH with the dependencies your script has (everything not guaranteed by POSIX, for example). E.g. with Nix `export PATH := $(shell nix-shell -p DEPENDENCY1 DEPENDENCY2 --run 'echo $$PATH')` Will cause `make` to include DEPENDENCY1 and DEPENDENCY2 from the Nix store in $PATH for the rest of the Makefile. You can get more complex and pin particular versions where it matters. Other cross-platform package management tools presumably have similar tricks that can be used, or you can bundle binaries for the tools you need. Then your build instructions only need to tell the user to have Make and the package management tool installed, and everything else can be set up in the Makefile. Of course this is a PITA.

No, correct. But it is a good example of something that you might expect to be more standard than it is between platforms, because of its age and relative ubiquity, where the differences get highlighted when trying to create (not just with make but other tools too) a consistent build process for a project.

czx4f4bd 4y ago
Yeah, variance between different system utilities is one of the biggest underrated perils of shell scripting. For a long time, I worked on a team that mostly used Macs to administer Linux servers, which led to some confusing issues when people tested certain commands locally and then tried to use them on a server. It would be nice if shellcheck had checks to detect common BSD/GNU incompatibilities and warn about them so you don't have to catch them in the moment.
- hulitu 4y ago
  I think that if one aims for compatibility , then it shall use POSIX.

arp242 4y ago

It wasn't claimed to be a bug.

SAI_Peregrinus 4y ago

But it is a bug in your Makefile to assume a particular version of a tool (or path to a tool, etc) without first checking (or otherwise forcing the correct thing to be used). For forcing the existence of tools, you can start your Makefile by setting up $PATH with the dependencies your script has (everything not guaranteed by POSIX, for example). E.g. with Nix `export PATH := $(shell nix-shell -p DEPENDENCY1 DEPENDENCY2 --run 'echo $$PATH')` Will cause `make` to include DEPENDENCY1 and DEPENDENCY2 from the Nix store in $PATH for the rest of the Makefile. You can get more complex and pin particular versions where it matters. Other cross-platform package management tools presumably have similar tricks that can be used, or you can bundle binaries for the tools you need. Then your build instructions only need to tell the user to have Make and the package management tool installed, and everything else can be set up in the Makefile. Of course this is a PITA.