3 ms·

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

by rixed 2y ago

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.

lmm 2y ago
> 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..
- rixed 2y ago
  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.
  - lmm 2y ago
    > 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.

by rixed 2y ago

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.

lmm 2y ago

> 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..

rixed 2y ago
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.
- lmm 2y ago
  > 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.