Hacker News Reader

Comment by t43562 | Hacker News Reader

Make's BIG problem (IMO of course) is that the commands are executed in the system shell.

If make supplied it's own shell language, a simplified one, then everything would be fantastic.

For one thing, cross platform builds would be much easier to get working as there would be no issue about "is the default shell bash or ash or sh or dash or ksh or whatever" and on Windows there would be no need to use cygwin.

The other thing is there would not need to be such a huge clash between the way expansion works in shells versus make which is very confusing when you combine the two.

View on HN

> If make supplied it's own shell language, a simplified one, then everything would be fantastic.

We did exactly that in build2, a modern make re-thought. And we provide a bunch of standard utilities like sed, find, etc., that work the same everywhere, including Windows. Here is an example of a non-trivial recipe: https://github.com/build2/libbuild2-autoconf/blob/17f637c1ca...

There's nothing stopping you from specifying an explicit shell in your Makefile (see: https://www.gnu.org/software/make/manual/make.html#Choosing-...).

You could set it to Ash, Bash, Perl, Python, execline, Docker exec, or whatever you want really. You can also set that variable on a per-recipe basis, if you have one recipe that needs a custom shell.

(note to any GNU Make maintainers who might see this: it would be really helpful to be able to set .ONESHELL on a per-recipe basis as well!)

Or even emacs, AS Amy Grinn showed last Werk at Fosdem.

https://fosdem.org/2025/schedule/event/fosdem-2025-5139-org-...

I always do in fact do that. SHELL:=/usr/bin/bash or whatever

The problem is that bash isn't there on windows and not even on all Linuxes so if I supply you with a makefile there's no way to be sure you can use it.

If make included a language then I don't need to worry about your dependencies - not even which version of bash you have. This would cause a makefile to be FAR more useful.

Yes, but where do you stop? In make shell one would routinely call rm, sed, find... should they be included too? So instead of make including a shell, it would be simpler if busybox included a make.

> In make shell one would routinely call rm, sed, find... should they be included too?

If you want to use it as a build tool, yes. The most successful build tools build hermetically, with the build definition specifying the versions of anything and everything that is needed to perform the build. (With Maven you even specify e.g. what version of the Java compiler to use, and it will download and use that version).

> So instead of make including a shell, it would be simpler if busybox included a make.

Can busybox be used portably from e.g. a user's homedir? I've only ever seen it used as the main system in /bin etc..

Well, I believe make is already the most succesful build tool, at least on every platform I'm caring about (ie any variant of unices + few more).

What you are describing looks like packaging more than building. Pinning the versions of everything is not the build tool job.

I understand the standpoint of software publishers who want to limit the number of environments they have to suport, but proprietary software is not the use case that every tools should be optimizing for.

When, a nix user or a gentoo user decides that she wants this version of library X with this version of library Y, that's not make's job to overide her decision, is it? We need some flexibility.

> When, a nix user or a gentoo user decides that she wants this version of library X with this version of library Y, that's not make's job to overide her decision, is it? We need some flexibility.

The user should absolutely be able to override it, but library X's build system should have some defaults and changing them should be a deliberate choice. "Build against whatever happens to currently be installed, and hope you get lucky and wind up with something that works" is not a great build experience.

Reply on news.ycombinator.com