3 ms·
If your rules have side-effects that aren't reflected in the dependency part of the declaration but nonetheless depended upon, running the jobs in parallel mean
by asveikau 7y ago
If your rules have side-effects that aren't reflected in the dependency part of the declaration but nonetheless depended upon, running the jobs in parallel means the order of execution varies instead of being sequential, so sometimes you may get a file not found on something produced in an earlier rule.
If make knows about all the inputs and outputs of every rule, it can make sure dependencies are built before they are used. The problem occurs when the makefile doesn't tell make about every dependency.
Also the rule scripts themselves can have race conditions. A trivial example is if they end up using the same temp filename when doing work.
- IshKebab 7y agoYes I know. But the order of execution can vary even if you don't run in parallel. For example if you have two targets, A and B, and B depends on A's output but you forgot to say so, then `make` can build B before A even if you don't use the `-j` option.
- asveikau 7y agoI thought the behavior I have seen is it's always in the order that the targets are specified. So if you have: all: A B Then if both need a rebuild A is always first, except when -j breaks that. But I can't say I have played close attention to every time I have typed make.
- IshKebab 7y agoAh right, but that's just a lucky coincidence. Make is perfectly within its rights to randomise the order of A and B even if you don't specify `-j`. And if you're driving Make from some other system, e.g. CMake, you really have no idea what order stuff is going to end up in the makefiles anyway.