4 ms·

> 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

by _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.
- slavik81 11y ago
  The impact of those changes is rather different. In the case of make, your build would probably break. In the case of gcc, your program's behaviour would silently change.
  - MereInterest 11y ago
    In the case of make, with missing dependencies, it can result in a file not being re-compiled when it should be. If you are compiling C, this can result in the definition of a function definition being different in two different compilation units. When one of those compilation units calls a function defined in the other, your program's behavior breaks. All due to a change in the build tool.
    - slavik81 11y ago
      That's true. I qualified my statement with probably because there are exceptions. Protecting against those sorts of errors is why my release candidates are done with a clean build and newly fixed bugs are reverified on that package before release.

by _pmf_ 11y ago

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.

slavik81 11y ago
The impact of those changes is rather different. In the case of make, your build would probably break. In the case of gcc, your program's behaviour would silently change.
- MereInterest 11y ago
  In the case of make, with missing dependencies, it can result in a file not being re-compiled when it should be. If you are compiling C, this can result in the definition of a function definition being different in two different compilation units. When one of those compilation units calls a function defined in the other, your program's behavior breaks. All due to a change in the build tool.
  - slavik81 11y ago
    That's true. I qualified my statement with probably because there are exceptions. Protecting against those sorts of errors is why my release candidates are done with a clean build and newly fixed bugs are reverified on that package before release.