18 ms·

I would like to call attention to `just` (https://github.com/casey/just https://github.com/casey/just) which is a modern take on "make if we didn't have to keep

I would like to call attention to `just` (https://github.com/casey/just https://github.com/casey/just) which is a modern take on "make if we didn't have to keep it backwards compatible", and more focussed on just task running rather than tracking dependencies.

marcuskaz 5y ago
Yes! This is what a modern task runner should be. Includes ability to list recipes, and a consistent format between multiple platforms. Just two things Make doesn't have.
michidk 5y ago
I was just going to say that. Just is awesome and I use it it most of my projects.
enriquto 5y ago
There's no -j option nor mention of parallelism on the docs. Does it run independent targets in parallel? This is easily the main feature of make. I don't understand how it can work in parallel if targets are not somehow associated to files. What's the advantage to a shell script with separate sub-commands, then?
- q3k 5y ago
  ‘just’ apparently isn’t a build system, just a ‘task runner’. So I assume it doesn’t need/want to implement parallelism.
  - dahfizz 5y ago
    It sounds like `just` is not a replacement for make, then. It seems like it could be a nice wrapper on top, i.e. `just build` could invoke the make build system.
  - toast0 5y ago
    Parallelism is pretty useful for just a 'task runner' too. I've (ab)used Make for server pushes, and sometimes you want those to run one at a time, and sometimes you want -j 100 (sometimes -j 100 is even effective).
    - jandrese 5y ago
      The key aspect here is that since Make knows what the dependencies are it has enough information to automatically parallelize the task. A simple task runner would need to be specifically configured with the dependency graph, and if you have that you've just re-created Make.
      - toast0 5y ago
        If I'm using the task runner for deployment, it doesn't need to have a sophisticated dependency graph, it "just" needs to be able to have a list of tasks that are declared as independent/parallelizable, and a way to specify how many to run at once. Sophisticated dependencies are nice to have of course, maybe make push-all transitively includes building the thing locally, but it's still useful to have just the push step (or the reload step, etc), have optional parallelism. If you start to build a tool that does do these things first, in order; then these things in any order; then these other things, that does look a lot like Make. but if you just handle ordered steps and independent steps, and let a person do the mixing, then it's not nearly as much work as Make.
        enriquto 5y ago
        > Sophisticated dependencies are nice to have What are you talking about? Make does not deal with "sophisticated" dependencies. Make is insultingly simple, not sophisticated at all. It's just a damn directed tree. The simplest data structure in computer science after the array. There are also some fancier shortcuts for expressing rules in makefiles, but you can ignore them and use only the simple stuff. That's already a much more powerful tool than "just".
jonhohle 5y ago
Tracking dependencies is what makes make make. Love it or hate it, Ant got this right (imho), and modern build systems almost universally get this wrong. Every language can run and compose tasks. Dependency tracking, parallelization, and language agnosticism are the killer features of make (again, imho).
- gnulinux 5y ago
  I agree with you on all grounds (I personally use make daily) however note that `make` checks dependencies via last updated time flag on files. I think it would have been a better default to cache based on hash of file. This way if document was modified, by hash wasn't changed, make shouldn't rebuild tasks that depend on this file.
  - enriquto 5y ago
    But computing the hashes of all the files would take the same time as rebuilding everything, or maybe even slower. And you'd need to re-compute all these hashes even for a no-op. It's absurd. The nice thing about dates is that they can be checked instantaneously, and independently of file size. If a file has changed, its date has, so it's all the information you need.
    - duped 5y ago
      Computing the SHA sum of a file is plenty fast on modern hardware, nowhere close to the same time as a rebuild.
      - slaymaker1907 5y ago
        Yep, I can take the sha256sum over my all my project's (vendored) dependencies in 10ms using the command: time find ./vendor -type f -print0 | sort -z | xargs -0 sha256sum | sort -k2 | sha256sum Note if using this code for practical purposes, you should be sure your collation is set appropriately. That's taken with 1280 files that are in total 19MB. For raw throughput, you can use BLAKE2 for even more speed https://www.blake2.net/ https://www.blake2.net/
oftenwrong 5y ago
`just` seems like a useful tool, but it only covers a secondary use case of `make`. `make` without a dependency graph is like a bicycle without wheels.
- masklinn 5y ago
  All I can say is that I’ve only ever used make as a task runner myself, so just matches my need way better. IME make’s model is often too simplistic to be of use, so it simply gets in the way of tools already doing things internally with proper insight, or requires force-cleaning everything because it's too dumb and just breaks the build when you e.g. switch branch. Just’s author is also looking at integrating `redo` for building / dependency tracking, though the issue has no activity since it’s been created.
  - jandrese 5y ago
    If you find yourself running "make clean" because it is "too dumb" you've built your Makefile wrong. Usually it means you've tried to manually re-create the inherent Make rules and have gotten it wrong somewhere. This is incredibly common, since the inherent rules are not always the same across various versions of Make and people don't always trust them. IMHO, this is the primary weakness of Make. The standardization efforts never really happened so you have various forks of 1980s code with annoying incompatibilities. BSD Make is missing some of the implicit build rules from GNU Make (only able to compile simple single source file applications without an explicit rule), and Windows Make tends to be extremely primitive. Worse, Make still in 2022 can't handle spaces in file names, like c:\Documents and Users\. I would be so much happier if everybody could standardize on one flavor of Make. Probably GNU Make.
    - teddyh 5y ago
      > I would be so much happier if everybody could standardize on one flavor of Make. Probably GNU Make. With included Guile scripting support! https://www.gnu.org/software/make/manual/html_node/Guile-Example.html https://www.gnu.org/software/make/manual/html_node/Guile-Exa...
pletnes 5y ago
The python library/CLI tool «invoke» is also nice, although requires python.

marcuskaz 5y ago

Yes! This is what a modern task runner should be. Includes ability to list recipes, and a consistent format between multiple platforms. Just two things Make doesn't have.

michidk 5y ago

I was just going to say that. Just is awesome and I use it it most of my projects.

enriquto 5y ago

There's no -j option nor mention of parallelism on the docs. Does it run independent targets in parallel? This is easily the main feature of make. I don't understand how it can work in parallel if targets are not somehow associated to files. What's the advantage to a shell script with separate sub-commands, then?

q3k 5y ago
‘just’ apparently isn’t a build system, just a ‘task runner’. So I assume it doesn’t need/want to implement parallelism.
- dahfizz 5y ago
  It sounds like `just` is not a replacement for make, then. It seems like it could be a nice wrapper on top, i.e. `just build` could invoke the make build system.
- toast0 5y ago
  Parallelism is pretty useful for just a 'task runner' too. I've (ab)used Make for server pushes, and sometimes you want those to run one at a time, and sometimes you want -j 100 (sometimes -j 100 is even effective).
  - jandrese 5y ago
    The key aspect here is that since Make knows what the dependencies are it has enough information to automatically parallelize the task. A simple task runner would need to be specifically configured with the dependency graph, and if you have that you've just re-created Make.
    - toast0 5y ago
      If I'm using the task runner for deployment, it doesn't need to have a sophisticated dependency graph, it "just" needs to be able to have a list of tasks that are declared as independent/parallelizable, and a way to specify how many to run at once. Sophisticated dependencies are nice to have of course, maybe make push-all transitively includes building the thing locally, but it's still useful to have just the push step (or the reload step, etc), have optional parallelism. If you start to build a tool that does do these things first, in order; then these things in any order; then these other things, that does look a lot like Make. but if you just handle ordered steps and independent steps, and let a person do the mixing, then it's not nearly as much work as Make.
      - enriquto 5y ago
        > Sophisticated dependencies are nice to have What are you talking about? Make does not deal with "sophisticated" dependencies. Make is insultingly simple, not sophisticated at all. It's just a damn directed tree. The simplest data structure in computer science after the array. There are also some fancier shortcuts for expressing rules in makefiles, but you can ignore them and use only the simple stuff. That's already a much more powerful tool than "just".

jonhohle 5y ago

Tracking dependencies is what makes make make. Love it or hate it, Ant got this right (imho), and modern build systems almost universally get this wrong. Every language can run and compose tasks. Dependency tracking, parallelization, and language agnosticism are the killer features of make (again, imho).

gnulinux 5y ago
I agree with you on all grounds (I personally use make daily) however note that `make` checks dependencies via last updated time flag on files. I think it would have been a better default to cache based on hash of file. This way if document was modified, by hash wasn't changed, make shouldn't rebuild tasks that depend on this file.
- enriquto 5y ago
  But computing the hashes of all the files would take the same time as rebuilding everything, or maybe even slower. And you'd need to re-compute all these hashes even for a no-op. It's absurd. The nice thing about dates is that they can be checked instantaneously, and independently of file size. If a file has changed, its date has, so it's all the information you need.
  - duped 5y ago
    Computing the SHA sum of a file is plenty fast on modern hardware, nowhere close to the same time as a rebuild.
    - slaymaker1907 5y ago
      Yep, I can take the sha256sum over my all my project's (vendored) dependencies in 10ms using the command: time find ./vendor -type f -print0 | sort -z | xargs -0 sha256sum | sort -k2 | sha256sum Note if using this code for practical purposes, you should be sure your collation is set appropriately. That's taken with 1280 files that are in total 19MB. For raw throughput, you can use BLAKE2 for even more speed https://www.blake2.net/ https://www.blake2.net/

oftenwrong 5y ago

`just` seems like a useful tool, but it only covers a secondary use case of `make`. `make` without a dependency graph is like a bicycle without wheels.

masklinn 5y ago
All I can say is that I’ve only ever used make as a task runner myself, so just matches my need way better. IME make’s model is often too simplistic to be of use, so it simply gets in the way of tools already doing things internally with proper insight, or requires force-cleaning everything because it's too dumb and just breaks the build when you e.g. switch branch. Just’s author is also looking at integrating `redo` for building / dependency tracking, though the issue has no activity since it’s been created.
- jandrese 5y ago
  If you find yourself running "make clean" because it is "too dumb" you've built your Makefile wrong. Usually it means you've tried to manually re-create the inherent Make rules and have gotten it wrong somewhere. This is incredibly common, since the inherent rules are not always the same across various versions of Make and people don't always trust them. IMHO, this is the primary weakness of Make. The standardization efforts never really happened so you have various forks of 1980s code with annoying incompatibilities. BSD Make is missing some of the implicit build rules from GNU Make (only able to compile simple single source file applications without an explicit rule), and Windows Make tends to be extremely primitive. Worse, Make still in 2022 can't handle spaces in file names, like c:\Documents and Users\. I would be so much happier if everybody could standardize on one flavor of Make. Probably GNU Make.
  - teddyh 5y ago
    > I would be so much happier if everybody could standardize on one flavor of Make. Probably GNU Make. With included Guile scripting support! https://www.gnu.org/software/make/manual/html_node/Guile-Example.html https://www.gnu.org/software/make/manual/html_node/Guile-Exa...

pletnes 5y ago

The python library/CLI tool «invoke» is also nice, although requires python.