4 ms·

Yeah but if you use bare tools then it’s hard to change them and the interface may differ project to project. If you let the JS developers pick your universal b

Yeah but if you use bare tools then it’s hard to change them and the interface may differ project to project. If you let the JS developers pick your universal build tool then they’ll want to change it annually because now the old one they loved is “terrible” and some other thing is great and is definitely the way forward. Plus then you’ll need node on every machine that needs to run the build, and probably you’ll want to lock the version and not use the one in LTS OS releases because those are too old so now all your poor non-JS developers are installing NVM and Node and a pile of other crap. Or you can just make everyone wrap their build tools in make.

gravypod 6y ago
The solution here is to choose a build system that is language agnostic. The most common of these is docker & docker-compose. There's also the Blaze-likes (Pants, Buck, Bazel, Please) that let you hermetically include tools like node inside of the build chain. Make is not a "wrapper" it's a "translucent layer on top of" since it doesn't hide the deps on the underlying tools. When I do `docker build -t ... something` or `bazel build //something` I don't need to care if it's node, C++, Java, etc. I just need to know that it is a thing that I want to build. Make cannot deliver that to you as you need all of your system toolchains installed and you need to make sure your makefile works on every OS/system config.
- solraph 6y ago
  > Make is not a "wrapper" it's a "translucent layer on top of" since it doesn't hide the deps on the underlying tools. For me, that's kinda the point. If (when!) the underlying layers break, I can open up the Makefile and see exactly what was called, without too much abstraction. It's not there to provide complex build options, it's to provide aliases to the commonly used commands in a platform agnostic way. Most of my make commands are simply aliases for one or more commands, which are often something like `docker run --rm -it project_runner_image some_command` There's some real problems with Makefiles in the form of tabs as the prefix, running everything as a shell, weird platform specific versions, etc - but I've yet to see anything else which is as small, as universally available, with such a low barrier to entry. Most of the other options I've seen so far (and I'll be the first to admit I haven't looked very hard) seemed to either be overly complex for simple dev setups, or bound to a particular language.
- JamesSwift 6y ago
  Yes, you still have to make sure the underlying commands work because Make doesnt provide anything to isolate the commands. But that is also sort of my point: make is nothing but a generic task runner on top of what you are already doing. Its just about having commands and conventions that dont change depending on the underlying systems. I agree that blaze is the better option, but all the benefits it provides comes with a greater up-front cost, where its not necessarily possible to drop-in on a project and run with. Also notable is that blaze is inspired by and is a replacement for make. So in a lot of ways, make is a poor mans blaze now.

gravypod 6y ago

The solution here is to choose a build system that is language agnostic. The most common of these is docker & docker-compose. There's also the Blaze-likes (Pants, Buck, Bazel, Please) that let you hermetically include tools like node inside of the build chain. Make is not a "wrapper" it's a "translucent layer on top of" since it doesn't hide the deps on the underlying tools. When I do `docker build -t ... something` or `bazel build //something` I don't need to care if it's node, C++, Java, etc. I just need to know that it is a thing that I want to build. Make cannot deliver that to you as you need all of your system toolchains installed and you need to make sure your makefile works on every OS/system config.

solraph 6y ago
> Make is not a "wrapper" it's a "translucent layer on top of" since it doesn't hide the deps on the underlying tools. For me, that's kinda the point. If (when!) the underlying layers break, I can open up the Makefile and see exactly what was called, without too much abstraction. It's not there to provide complex build options, it's to provide aliases to the commonly used commands in a platform agnostic way. Most of my make commands are simply aliases for one or more commands, which are often something like `docker run --rm -it project_runner_image some_command` There's some real problems with Makefiles in the form of tabs as the prefix, running everything as a shell, weird platform specific versions, etc - but I've yet to see anything else which is as small, as universally available, with such a low barrier to entry. Most of the other options I've seen so far (and I'll be the first to admit I haven't looked very hard) seemed to either be overly complex for simple dev setups, or bound to a particular language.
JamesSwift 6y ago
Yes, you still have to make sure the underlying commands work because Make doesnt provide anything to isolate the commands. But that is also sort of my point: make is nothing but a generic task runner on top of what you are already doing. Its just about having commands and conventions that dont change depending on the underlying systems. I agree that blaze is the better option, but all the benefits it provides comes with a greater up-front cost, where its not necessarily possible to drop-in on a project and run with. Also notable is that blaze is inspired by and is a replacement for make. So in a lot of ways, make is a poor mans blaze now.