6 ms·

In 2019 Makefiles are a useful tool for automating project-level things. Too often webapps will require you to install X to install Y to run producing artifact

In 2019 Makefiles are a useful tool for automating project-level things. Too often webapps will require you to install X to install Y to run producing artifact Z. Since Make is old and baked and everywhere, specifying "make Z" is a useful project-level development process. It's not tied to a language (e.g. Tox) nor a huge runtime (Docker). Make is small enough in scope to be easy, and large enough to be capable without a lot of incantations. The big downside of Make, alas, is Windows compatibility.

logicallee 7y ago
>The big downside of Make, alas, is Windows compatibility. Isn't the big problem that you have no idea what it's doing to your system? Also that you aren't expected to be able to undo it. You can read the makefiles, of course, but it seems simpler not to have to. (Just update the necessary packages yourself, to the latest version.) Forgive me if this is naive of me.
- bch 7y ago
  If you write your own Makefiles you know what they do. They’re not that hard to grok and even hand-rolled Makefile use is (IMO) underrated.
  - dnautics 7y ago
    I always had trouble reading makefiles because the control flow is not very linear. At least with shell files basically everything is explicit.
    - sk5t 7y ago
      The dependency graph is one of the better reasons to use makefiles--think of the nonlinearity as a bonus!
    - aequitas 7y ago
      I often find the non linear way of working with Make an advantage. Since it allows you to break a big piece of procedural shell code with lots of control flow (if X is installed don't install again, etc) into small self contained functional pieces with clean input and output boundaries which can be run individually. It also greatly improves code reuse as every target/recipe can be considered a function.
      - dnautics 7y ago
        > Since it allows you to break a big piece of procedural shell code with lots of control flow (if X is installed don't install again, etc) into small self contained functional pieces with clean input and output boundaries which can be run individually At that point, I use a scripting -not shell- language (which is not as implicit) I don't program in c anymore, so my major workflow is all in one language; I write my server in the same language that do s the compilation, which is in the same language that does utilities like creating network tunnels to my lab nodes
- theon144 7y ago
  >Isn't the big problem that you have no idea what it's doing to your system? As opposed to what exactly? Any other alternative, e.g. separate shell scripts, "npm run" scripts in package.json, running a Docker image, hell even cmake or other make-like tools - does stuff you don't know about without reading the files either.
  - aequitas 7y ago
    With Docker at least everything is contained in the container. Which makes isolating and resetting environments a breeze. Something I worry about often is contaminating my system's 'state'. Which always leads to broken builds or incomplete build systems because a missing dependency is not spotted on your system because it was installed by some other tool some other time. I tend to write my Makefiles to create as much of a local dev environment as possible for every project. Using Python virtualenv/Pipenv/Poetry, Ruby vendored dirs, custom Gopath per project (using direnv), etc. Most tools support some sort of isolation/localisation, but it's often just not on by default.
    - jrumbut 7y ago
      I wish more tools did this, I almost always want a local, self-contained environment for everything. The few times I don't actively want I don't see much pain in having one. A couple minutes setup time, maybe? I have seriously considered hiring someone to audit and prune all the random little libraries and tools I've installed over the years for that one-off time I had to process a weird file format or wanted to try something from HN.
      - alephu5 7y ago
        Maybe you'd like NixOS?
        jrumbut 7y ago
        I'm fascinated by NixOS and am following it, just haven't had a lot of time to dive in yet. It does sound like the right idea. This is hypocritical as someone who doesn't use it but I hope more people use it.
pickdenis 7y ago
> The big downside of Make, alas, is Windows compatibility. You'd have to give me a _very_ compelling reason to support developers who use Windows, when Windows lacks these essential tools. Besides, don't people who develop on Windows live in WSL?
- astrobe_ 7y ago
  I've compiled a thing or two with MSYS2.
- ChristianGeek 7y ago
  Nope. I develop in Python, Java, and Kotlin on Windows and never touch WSL. Make is available natively through Chocolatey (a Windows package installer), but I prefer Gradle. (I also write code to run on Linux, but still prefer Gradle.)
  - noir_lord 7y ago
    Slightly off topic but what would you suggest for someone who is familiar with build systems but who hasn’t used gradle? I’m just getting into Kotlin and gradle isn’t something I’ve used before since I’m mostly web, .net til now.
  - OJFord 7y ago
    Why don't you use WSL? I can barely understand why you'd want to develop on Windows (ok, for non-Windows-only products) with it, but without it...
    - myoon 7y ago
      It isn't perfect. The IO performance is currently poor and it doesn't play well with Windows Defender (wastes a lot of CPU). Also, since your IDE would live in Windows, you can sometimes have issues with Windows and Linux both interacting with the same files.
    - bunderbunder 7y ago
      If you're already using a Vagrant or Docker-based development workflow, WSL doesn't really add much, and takes some things away. I/O performance, for example.
pixelrevision 7y ago
Will not be a problem for much longer :) https://www.theverge.com/2019/5/6/18534687/microsoft-windows-10-linux-kernel-feature https://www.theverge.com/2019/5/6/18534687/microsoft-windows...
- shpx 7y ago
  Hopefully Windows 11 is just a reskinned Ubuntu running all the old Windows programs through Wine.
  - mycall 7y ago
    I'll be surprised if there will ever be a Windows 11.
deng 7y ago
> The big downside of Make, alas, is Windows compatibility. GNU Make works fine on Windows. The sources come with a vcproj to build it natively, or you get it from ezwinports. At my dayjob, we have a pretty complicated build with GNU Make for cross-compiling our application to Arm and PowerPC, and it works on Windows, even with special Guile scripts to reduce the number of shell calls which are extremely slow on Windows.
- Const-me 7y ago
  Most popular folder on Windows is "My documents", it has a space at least in some Windows versions. Make doesn't support such paths: http://savannah.gnu.org/bugs/?712 http://savannah.gnu.org/bugs/?712 VBScript works better on Windows, IMO. Also works out of the box on all Windows versions since at least 2000 (on Win9x it was shipped with IE).
  - pinum 7y ago
    >Most popular folder on Windows is "My documents" Not really... not since XP, anyway. Unless you have a space in your username (which is a terrible idea for many other reasons), your "Documents" path is C:\Users\JohnSmith\Documents. "Program Files" is pretty much the only important path which is likely to have spaces, and your makefiles (hopefully!) don't need to touch that.
    - Const-me 7y ago
      On Windows, it's not up to me to decide where users will keep my stuff, and where it will work. Users decide. For a software to work fine on Windows, it must support spaces in files and paths. Also Unicode in files and paths. VBScript does, GNU Make doesn't. > which is a terrible idea for many other reasons If you use make to setup stuff, it's very possible you'll need to access "c:\Users\All Users" which does contain space in username. Also "c:\Program Files (x86)\Common Files" which contain more than one.
      - WhiteOwlLion 7y ago
deleted 7y ago
[deleted]
baroffoos 7y ago
Does make files ever actually work that way? In my experience they always require you to install a bunch of packages for libraries which usually only tells you the package names for ubuntu so you have to hunt down what the package is called on your distro or if that version of the package is even in the repos.
- kd5bjo 7y ago
  If you write them yourself they certainly can. For small projects, you can leave everything explicit and it works great. Can you break down your problem into a bunch of rules of the form “To produce this file, I need to run these shell commands, which read those other files over there as input”? If so, Make can take care of figuring out which steps actually need to be run.
- boomlinde 7y ago
  Most plain makefiles I've used use a tool like pkg-config to resolve library/header paths.

logicallee 7y ago

>The big downside of Make, alas, is Windows compatibility. Isn't the big problem that you have no idea what it's doing to your system? Also that you aren't expected to be able to undo it. You can read the makefiles, of course, but it seems simpler not to have to. (Just update the necessary packages yourself, to the latest version.) Forgive me if this is naive of me.

bch 7y ago
If you write your own Makefiles you know what they do. They’re not that hard to grok and even hand-rolled Makefile use is (IMO) underrated.
- dnautics 7y ago
  I always had trouble reading makefiles because the control flow is not very linear. At least with shell files basically everything is explicit.
  - sk5t 7y ago
    The dependency graph is one of the better reasons to use makefiles--think of the nonlinearity as a bonus!
  - aequitas 7y ago
    I often find the non linear way of working with Make an advantage. Since it allows you to break a big piece of procedural shell code with lots of control flow (if X is installed don't install again, etc) into small self contained functional pieces with clean input and output boundaries which can be run individually. It also greatly improves code reuse as every target/recipe can be considered a function.
    - dnautics 7y ago
      > Since it allows you to break a big piece of procedural shell code with lots of control flow (if X is installed don't install again, etc) into small self contained functional pieces with clean input and output boundaries which can be run individually At that point, I use a scripting -not shell- language (which is not as implicit) I don't program in c anymore, so my major workflow is all in one language; I write my server in the same language that do s the compilation, which is in the same language that does utilities like creating network tunnels to my lab nodes
theon144 7y ago
>Isn't the big problem that you have no idea what it's doing to your system? As opposed to what exactly? Any other alternative, e.g. separate shell scripts, "npm run" scripts in package.json, running a Docker image, hell even cmake or other make-like tools - does stuff you don't know about without reading the files either.
- aequitas 7y ago
  With Docker at least everything is contained in the container. Which makes isolating and resetting environments a breeze. Something I worry about often is contaminating my system's 'state'. Which always leads to broken builds or incomplete build systems because a missing dependency is not spotted on your system because it was installed by some other tool some other time. I tend to write my Makefiles to create as much of a local dev environment as possible for every project. Using Python virtualenv/Pipenv/Poetry, Ruby vendored dirs, custom Gopath per project (using direnv), etc. Most tools support some sort of isolation/localisation, but it's often just not on by default.
  - jrumbut 7y ago
    I wish more tools did this, I almost always want a local, self-contained environment for everything. The few times I don't actively want I don't see much pain in having one. A couple minutes setup time, maybe? I have seriously considered hiring someone to audit and prune all the random little libraries and tools I've installed over the years for that one-off time I had to process a weird file format or wanted to try something from HN.
    - alephu5 7y ago
      Maybe you'd like NixOS?
      - jrumbut 7y ago
        I'm fascinated by NixOS and am following it, just haven't had a lot of time to dive in yet. It does sound like the right idea. This is hypocritical as someone who doesn't use it but I hope more people use it.

pickdenis 7y ago

> The big downside of Make, alas, is Windows compatibility. You'd have to give me a _very_ compelling reason to support developers who use Windows, when Windows lacks these essential tools. Besides, don't people who develop on Windows live in WSL?

astrobe_ 7y ago
I've compiled a thing or two with MSYS2.
ChristianGeek 7y ago
Nope. I develop in Python, Java, and Kotlin on Windows and never touch WSL. Make is available natively through Chocolatey (a Windows package installer), but I prefer Gradle. (I also write code to run on Linux, but still prefer Gradle.)
- noir_lord 7y ago
  Slightly off topic but what would you suggest for someone who is familiar with build systems but who hasn’t used gradle? I’m just getting into Kotlin and gradle isn’t something I’ve used before since I’m mostly web, .net til now.
- OJFord 7y ago
  Why don't you use WSL? I can barely understand why you'd want to develop on Windows (ok, for non-Windows-only products) with it, but without it...
  - myoon 7y ago
    It isn't perfect. The IO performance is currently poor and it doesn't play well with Windows Defender (wastes a lot of CPU). Also, since your IDE would live in Windows, you can sometimes have issues with Windows and Linux both interacting with the same files.
  - bunderbunder 7y ago
    If you're already using a Vagrant or Docker-based development workflow, WSL doesn't really add much, and takes some things away. I/O performance, for example.

pixelrevision 7y ago

Will not be a problem for much longer :) https://www.theverge.com/2019/5/6/18534687/microsoft-windows-10-linux-kernel-feature https://www.theverge.com/2019/5/6/18534687/microsoft-windows...

shpx 7y ago
Hopefully Windows 11 is just a reskinned Ubuntu running all the old Windows programs through Wine.
- mycall 7y ago
  I'll be surprised if there will ever be a Windows 11.

deng 7y ago

> The big downside of Make, alas, is Windows compatibility. GNU Make works fine on Windows. The sources come with a vcproj to build it natively, or you get it from ezwinports. At my dayjob, we have a pretty complicated build with GNU Make for cross-compiling our application to Arm and PowerPC, and it works on Windows, even with special Guile scripts to reduce the number of shell calls which are extremely slow on Windows.

Const-me 7y ago
Most popular folder on Windows is "My documents", it has a space at least in some Windows versions. Make doesn't support such paths: http://savannah.gnu.org/bugs/?712 http://savannah.gnu.org/bugs/?712 VBScript works better on Windows, IMO. Also works out of the box on all Windows versions since at least 2000 (on Win9x it was shipped with IE).
- pinum 7y ago
  >Most popular folder on Windows is "My documents" Not really... not since XP, anyway. Unless you have a space in your username (which is a terrible idea for many other reasons), your "Documents" path is C:\Users\JohnSmith\Documents. "Program Files" is pretty much the only important path which is likely to have spaces, and your makefiles (hopefully!) don't need to touch that.
  - Const-me 7y ago
    On Windows, it's not up to me to decide where users will keep my stuff, and where it will work. Users decide. For a software to work fine on Windows, it must support spaces in files and paths. Also Unicode in files and paths. VBScript does, GNU Make doesn't. > which is a terrible idea for many other reasons If you use make to setup stuff, it's very possible you'll need to access "c:\Users\All Users" which does contain space in username. Also "c:\Program Files (x86)\Common Files" which contain more than one.
    - WhiteOwlLion 7y ago

deleted 7y ago

[deleted]

baroffoos 7y ago

Does make files ever actually work that way? In my experience they always require you to install a bunch of packages for libraries which usually only tells you the package names for ubuntu so you have to hunt down what the package is called on your distro or if that version of the package is even in the repos.

kd5bjo 7y ago
If you write them yourself they certainly can. For small projects, you can leave everything explicit and it works great. Can you break down your problem into a bunch of rules of the form “To produce this file, I need to run these shell commands, which read those other files over there as input”? If so, Make can take care of figuring out which steps actually need to be run.
boomlinde 7y ago
Most plain makefiles I've used use a tool like pkg-config to resolve library/header paths.