5 ms·

Regarding make, the author states: Parallelize different commands: Okay: There's no automatic way to parallelize different targets, though you can still para

Regarding make, the author states: Parallelize different commands: Okay: There's no automatic way to parallelize different targets, though you can still parallelize a single target using Bash. This is wrong, make has supported the -j flag since 1988: -j [jobs], --jobs[=jobs] Specifies the number of jobs (commands) to run simultaneously. If there is more than one -j option, the last one is effective. If the -j option is given without an argument, make will not limit the number of jobs that can run simultaneously.

microcolonel 11y ago
I can't believe anyone could use make in the last ~12 years without the -j flag. We've had dual cores at least for ages.
- Ace17 11y ago
  Actually, I think make should default to parallel builds.
  - spc476 11y ago
    It only works if all the dependencies are specified correctly, otherwise, the make will fail.
  - MereInterest 11y ago
    The problem there is that it would break makefiles that do not handle their dependencies correctly. With non-parallel builds, the order of execution is deterministic, and so you can get away with sloppiness in your dependencies. If it works the first time that you test it, it will continue to work. I can understand why they would be hesitant to change the default, as they would rather that old, tested scripts continue to work without modification.
    - hamstergene 11y ago
      It will also not work with recursive make invocations, e.g. when top level makefile simply invokes makefiles of several independent projects.
      - opk 11y ago
        This actually works fine in GNU make too. The parent make acts as a job server. The implementation is ingenious, see http://make.mad-scientist.net/papers/jobserver-implementation/ http://make.mad-scientist.net/papers/jobserver-implementatio...
    - _pmf_ 11y ago
      > The problem there is that it would break makefiles that do not handle their dependencies correctly. Serious question: In what way are Makefiles that are not specifying their dependencies correctly ever to be considered non-broken?
      - pgeorgi 11y ago
        As said: their behavior is still deterministic in non-parallel execution. And it looks like gnu make developers aren't like compiler developers that exploit any ambiguity as an excuse to really mess up somebody's day.
      - dllthomas 11y ago
        Of course, they are broken. If dependencies are specified incorrectly, there will be files that, if modified, do not lead to correct rebuilds. But that doesn't mean there aren't stable workflows using those broken files that are not sensitive to the brokenness.
      - MereInterest 11y ago
        It's the exact same argument that comes up whenever gcc improves their optimization algorithms by exploiting undefined behavior, making some code no longer work. In both cases, the original code was fundamentally broken from the start, and the change in tooling only revealed the brokenness, not causing it. I would completely see such makefiles as being broken.
- oriolid 11y ago
  I have a co-worker who was told about -j a couple of weeks ago. Before that, he would bill half an hour for every time he did a clean build.

microcolonel 11y ago

I can't believe anyone could use make in the last ~12 years without the -j flag. We've had dual cores at least for ages.

Ace17 11y ago
Actually, I think make should default to parallel builds.
- spc476 11y ago
  It only works if all the dependencies are specified correctly, otherwise, the make will fail.
- MereInterest 11y ago
  The problem there is that it would break makefiles that do not handle their dependencies correctly. With non-parallel builds, the order of execution is deterministic, and so you can get away with sloppiness in your dependencies. If it works the first time that you test it, it will continue to work. I can understand why they would be hesitant to change the default, as they would rather that old, tested scripts continue to work without modification.
  - hamstergene 11y ago
    It will also not work with recursive make invocations, e.g. when top level makefile simply invokes makefiles of several independent projects.
    - opk 11y ago
      This actually works fine in GNU make too. The parent make acts as a job server. The implementation is ingenious, see http://make.mad-scientist.net/papers/jobserver-implementation/ http://make.mad-scientist.net/papers/jobserver-implementatio...
  - _pmf_ 11y ago
    > The problem there is that it would break makefiles that do not handle their dependencies correctly. Serious question: In what way are Makefiles that are not specifying their dependencies correctly ever to be considered non-broken?
    - pgeorgi 11y ago
      As said: their behavior is still deterministic in non-parallel execution. And it looks like gnu make developers aren't like compiler developers that exploit any ambiguity as an excuse to really mess up somebody's day.
    - dllthomas 11y ago
      Of course, they are broken. If dependencies are specified incorrectly, there will be files that, if modified, do not lead to correct rebuilds. But that doesn't mean there aren't stable workflows using those broken files that are not sensitive to the brokenness.
    - MereInterest 11y ago
      It's the exact same argument that comes up whenever gcc improves their optimization algorithms by exploiting undefined behavior, making some code no longer work. In both cases, the original code was fundamentally broken from the start, and the change in tooling only revealed the brokenness, not causing it. I would completely see such makefiles as being broken.
oriolid 11y ago
I have a co-worker who was told about -j a couple of weeks ago. Before that, he would bill half an hour for every time he did a clean build.