[adekok]

There is a bottom-up build system: http://gittup.org/tup/

It's very nice, but the cost of changing from Make means that most people don't use it. The Ninja design docs reference Tup, so they're aware it exists.

Solving the Latex problem of “Label(s) may have changed. Rerun to get cross-references right.” is hard. The assumption of make is that the only state is in the file system. i.e. running the same inputs should produce the same outputs. The above message shows that Latex violates this constraint.

The simple solution is to (ugh) write a wrapper script which runs Latex, and creates another output file if the labels are wrong. Only after the labels are right does the output file stop changing.

Which means the dependencies are a circular loop. Which Make doesn't handle. <sigh>

The limitations of 1970s design is apparent. But Make is so astonishingly powerful that anything new has to be much better than Make. So far that doesn't seem to have happened.

[gjulianm]

Just as a practical tip: use latexmk, it's an utility that runs all the necessary tools the necessary number of times to get everything right (labels, cross references, indexes, etc). It works really nice with Make.

[agumonkey]

I found make was also too much coupled to some programming practices (implicit extension-based rules) and not lazy enough, hence the dual design of tup. Tup felt a little too restrictive even though the smaller scope is a relief. Truth lies in the middle, I'm sure make will have a prodigal son sooner or later.

[dmckeon]

To avoid the implicits:

  make --no-builtin-rules --no-builtin-variables

at least as of: GNU Make 3.82

I think that at this point, with 37-some years worth of Makefiles on the planet, a competitive replacement for make with a different syntax or format would need to provide tools to process or translate old & new formats to the other format, as Perl did with the (uni-directional) a2p and s2p tools for awk and sed scripts, so that people considering a transition could make the leap more easily and with greater confidence.

[agumonkey]

hehe seems like I didn't RTF-make-M deep enough. Indeed a migration plan would be of immense value. But I fear more than syntax, it's make semantics that would hurt this plan, since AFAIK it has non trivial scopes for variables. Complex makefiles translation might prove intractable.

[ori_b]

> The simple solution is to (ugh) write a wrapper script which runs Latex, and creates another output file if the labels are wrong. Only after the labels are right does the output file stop changing.

The other alternative is to treat the rerunning of latex until it reaches a fixed point as a single build step, instead of multiple ones.

[cperciva]

Except that rewriting Make to handle LaTeX wouldn't work, because "keep re-running LaTeX until the labels stop changing" is turing-complete.

[TheLoneWolfling]

I don't see how the first follows from the second.

"keep re-running LaTeX until the labels stop changing" is relatively easily done. If nothing else, use a loop detection algorithm.

Sure, theoretically it may "never" stop. But you already have that problem.

[cperciva]

Being Turing complete means that not only might it not stop, but you can't even reliably determine if it won't stop.

[TheLoneWolfling]

And? That's no different than the build script calling any external executable. It may stop, it may not stop, it may format the hard drive. Make doesn't (and shouldn't) care.

[anyfoo]

Again: So what? The build system doesn't need to care whether it will stop or not. It will just run it, and if it doesn't stop it doesn't stop and will require human intervention, but you have the same problem with running LaTeX manually. At some point, you will have to decide whether you think it makes sense to add another iteration, and if without a build system you decide after 10 iterations that you probably should stop, then you can also tell your build systems that it should just give up at 10 iterations.

C is also turing complete, so I cannot reliably determine if my program will stop or not. Doesn't preclude me from running it.

[euyyn]

For most usual cases you will be able, I would guess.