dataflow.f.tex: dataflow.tex
lhs2tex -o $@ $<
It really should be that simple. Is that not working for you?
Oh, but... the makefile tries to precompute some of the dependencies
based on .tex files in the directory. That part might be breaking. I
see.
Also, we don't do the jobname thing - that could be significant. Is
there any reason your source/target files can't be named differently?
For example, you source could be "dataflow.haskell" and your target
would be "dataflow.tex". Then jobname shouldn't be necessary, as it
will default to the basename of the .tex file, right?
If that doesn't work, I could add a special comment directive that
would create the appropriate option. That shouldn't be too hard to
do.
We have a couple of options if the above doesn't work properly (just
thinking out loud here):
- lhs2tex is a standard utility - I could just add support for it
directly to the makefile. Should be relatively easy.
- create a .py or .sh or .pl script called, e.g., dataflow.tex.sh that
generates your dataflow.tex file, and all it does is calls lhs2tex.
This works today (type "make help | less" and look for \.sh to get
instructions on how to do this).
In summary, we have two different issues that we're tackling:
1) jobname does not get set
- We can either change file names to fix this (so that the final .tex
file is <jobname>.tex), or
- We can add a special comment directive, so that you would do
something like "%%jobname=stuff" in the .tex file and the makefile
will push that through to the options properly.
2) Some other problem might exist with build dependencies
- We can either add lhs2tex support directly, or
- You can write a .tex.sh script (or similar) to generate the file the
way you want.
Thoughts welcome!
Right, this doesn't work correctly. When I have Targets.ini with just
that line (and no Makefile.ini), bibtex won't run on the first run ,
though it will on the second.
So it's not a huge deal, but it would be nice to fix.
> In summary, we have two different issues that we're tackling:
>
> 1) jobname does not get set
>
I don't think this matters - I suspect its the automatic dependency
calculations that are getting me.
> 2) Some other problem might exist with build dependencies
>
> - We can either add lhs2tex support directly, or
> - You can write a .tex.sh script (or similar) to generate the file the
> way you want.
I prefer the second, but could go with either. In the second case, I
want to process all of my tex files using lhs2tex. Do I need to create
.sh for every file or can I create one .sh (and some makefile magic)
that adds the right dependencies?
In the first case, would you add ".lhs" files to the automatic
dependency calculations? That sort of works for me, except I tend to
edit ".tex" files (because they are a lot more prose than code). I
don't mind switching extensions if necessary.
I don't mind hacking the Makfile to experiment - where are
dependencies based on ".tex" files built?
Thanks for your detailed reply!
Justin
This strategy is working for me. I added .f.tex.sh files for each chapter:
dataflow.f.tex.sh
intro.f.tex.sh
Unfortunately, the scripts run everytime I rebuild my document - e.g.
make dataflow.f.pdf will always execute dataflow.f.tex.sh. If I read
the Makefile correctly, this rule:
%.tex:: %.tex.sh
$(QUIET)$(call run-script,$(SHELL),$<,$@)
plus the fact that %.tex.sh is PHONY, ensures that the shell script always runs.
Is there a way to specify that dataflow.f.tex.sh should only run if
dataflow.tex has changed, or should I try one of the other strategies?
I found that if I replaced the .sh rule with an empty recipe in
Targets.ini, like so:
%.tex:: %.tex.sh
The presence of the shell scripts sets the dependencies up like I
need, but they don't need to execute. A %.f.tex rule does what I want,
and only executes when the .f.tex output needs to be updated:
%.f.tex: %.tex
lhs2tex --poly -o $@ $<
In short, everything is working just fine.
Thanks for your help!
Justin
Yeah, that sounds about right :-(.
>
> So it's not a huge deal, but it would be nice to fix.
>
>> In summary, we have two different issues that we're tackling:
>>
>> 1) jobname does not get set
>>
>
> I don't think this matters - I suspect its the automatic dependency
> calculations that are getting me.
Yes, most likely. I'll ignore the jobname issue for now then.
>
>
>> 2) Some other problem might exist with build dependencies
>>
>> - We can either add lhs2tex support directly, or
>> - You can write a .tex.sh script (or similar) to generate the file the
>> way you want.
>
> I prefer the second, but could go with either. In the second case, I
> want to process all of my tex files using lhs2tex. Do I need to create
> .sh for every file or can I create one .sh (and some makefile magic)
> that adds the right dependencies?
Currently, using .sh (or similar) is something you would do for every
file. It's a pain, but this feature isn't used much, for reasons you
discuss below.
You probably can use some makefile magic to generate .sh files from a
master file. That should be easy enough.
>
> In the first case, would you add ".lhs" files to the automatic
> dependency calculations? That sort of works for me, except I tend to
> edit ".tex" files (because they are a lot more prose than code). I
> don't mind switching extensions if necessary.
Yeah, I think that switching extensions would make a lot more sense -
edit the "real" source file, then have .tex generated from that. It
isn't too hard to add another file as a .tex source. The dependency
generation is sort of deep in this case, but the machinery is all
there, so I'm sure we could get it working properly.
>
> I don't mind hacking the Makfile to experiment - where are
> dependencies based on ".tex" files built?
All over the place, unfortunately. The main thing that you need to
know is that we have to create a list of "stems" based on what can be
a tex source. You'll see things in the file like "all_stems.tex" and
later things like "all_stems_source", "all_stems_script",
"all_stems_ss", etc. Getting those right is the key. After that is
set up, things just work.
We are doing something rather different here, though. We would be
generating .tex from something that is not a script, so we'll want to
create a new stem type for it (e.g., all_stems_preproc or something)
and make sure that it ends up in the all_stems_ss variable along with
sources and scripts.
We don't want to add it to all_stems_scripts because there is magic in
the makefile to cause those to rebuild *every time*, which is
definitely not what you want (there is no way, without solving the
Halting Problem, of knowing when a script's dependencies need to be
rebuilt, so we call the script every time, which is the behavior you
noticed).
Anyway, feel free to hack away. I'm also happy to help tackle this.
Either way, let's move discussion over to the issue tracker where we
can more easily mark progress on this.
Thanks!
- C
Wow, that is *super devious*. I love it, but I'm also happy to add
direct support if you'd like. :-)