The original sin here is generating the dependencies from the source files in the same step that was used to generate the object files. The only way to ensure that Make observes structural changes in the dependency DAG is if the graph is rebuilt.
Good old "make depend". If only it didn't add a significant overhead...
You can get make to only re-generate its rules incrementally based on what was changed.
Thanks, the `!macro` thing seems to be what I was looking for. Having intermediary temporary files is of course fine. The use-case at that time was to convert a LaTeX file containing a TIKZ image (therefore having a .tikz file extension) to an SVG which required compiling the LaTeX code to PDF, cropping the PDF and converting it to SVG. Since there were multiple occurrences of this across the project, I wanted to hav…
How does !macro rid you of that portability issue? One way or another, you'd need to have a command that does that whole sequence of operations. If it's inline, I'd expect same portability problem (`&&` in Bash corresponds to something else in `.bat`).
Thanks, the `!macro` thing seems to be what I was looking for. Having intermediary temporary files is of course fine. The use-case at that time was to convert a LaTeX file containing a TIKZ image (therefore having a .tikz file extension) to an SVG which required compiling the LaTeX code to PDF, cropping the PDF and converting it to SVG. Since there were multiple occurrences of this across the project, I wanted to hav…
How does !macro rid you of that portability issue? One way or another, you'd need to have a command that does that whole sequence of operations. If it's inline, I'd expect same portability problem (`&&` in Bash corresponds to something else in `.bat`).
You are right, glancing over the Man page I thought you could just specify multiple commands. But it doesn't seem like it. So, my problem persists.
How does !macro rid you of that portability issue? One way or another, you'd need to have a command that does that whole sequence of operations. If it's inline, I'd expect same portability problem (`&&` in Bash corresponds to something else in `.bat`).
You are right, glancing over the Man page I thought you could just specify multiple commands. But it doesn't seem like it. So, my problem persists.
What you could do is use Tup's LUA support (you can write tupfiles and tuprules in LUA, and you can define and use LUA functions in them): have each rule handle just one step of your process, generate the whole necessary DAG of rules, encapsulate all of that in a LUA function defined in tuprules.lua and call that function in tupfile.lua for every diagram you want to generate. One thing that you lose is the ability to use `foreach` with your construction (other than by creating a variant of your constructions that embeds foreachness, or by using tup.glob and iterating).
You are right, glancing over the Man page I thought you could just specify multiple commands. But it doesn't seem like it. So, my problem persists.
What you could do is use Tup's LUA support (you can write tupfiles and tuprules in LUA, and you can define and use LUA functions in them): have each rule handle just one step of your process, generate the whole necessary DAG of rules, encapsulate all of that in a LUA function defined in tuprules.lua and call that function in tupfile.lua for every diagram you want to generate. One thing that you lose is the ability to…
I specifically wanted to avoid the LUA support. As soon as we get there I'd rather go with Ruby and Rakefiles.