Propositions as Filenames, Builds as Proofs: The Essence of Make
1–10 of 20 posts
Re: Propositions as Filenames, Builds as Proofs: The Essence of Make
#2There 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.
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.
Re: Propositions as Filenames, Builds as Proofs: The Essence of Make
#3There 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…
Except that rewriting Make to handle LaTeX wouldn't work, because "keep re-running LaTeX until the labels stop changing" is turing-complete.
Re: Propositions as Filenames, Builds as Proofs: The Essence of Make
#4There 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…
> 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.
Re: Propositions as Filenames, Builds as Proofs: The Essence of Make
#5There 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…
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.
Re: Propositions as Filenames, Builds as Proofs: The Essence of Make
#6There 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…
Except that rewriting Make to handle LaTeX wouldn't work, because "keep re-running LaTeX until the labels stop changing" is turing-complete.
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.
Re: Propositions as Filenames, Builds as Proofs: The Essence of Make
#7Earlier quoted context omitted.
Except that rewriting Make to handle LaTeX wouldn't work, because "keep re-running LaTeX until the labels stop changing" is turing-complete.
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.
Being Turing complete means that not only might it not stop, but you can't even reliably determine if it won't stop.
Re: Propositions as Filenames, Builds as Proofs: The Essence of Make
#8If anyone's interested, I generalized make to work beyond files (eg: if the tarball doesn't exist on the website already, then it must be uploaded; before uploading, the tarball must have been tested). Also to add parameters to rules, which work a bit like .c.o: rules in make, but fully general with multiple parameters.
To be fair I haven't worked hard to make this very usable, but I do use it myself a lot for all sorts of interesting things:
The tool itself: http://git.annexia.org/?p=goaljobs.git;a=summary
A subset of recipes I use regularly: http://git.annexia.org/?p=goals.git;a=summary
Re: Propositions as Filenames, Builds as Proofs: The Essence of Make
#9Earlier quoted context omitted.
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.
Being Turing complete means that not only might it not stop, but you can't even reliably determine if it won't stop.
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.
Re: Propositions as Filenames, Builds as Proofs: The Essence of Make
#10Earlier quoted context omitted.
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.
Being Turing complete means that not only might it not stop, but you can't even reliably determine if it won't stop.
For most usual cases you will be able, I would guess.