Closed GoogleCodeExporter closed 9 years ago
It looks like in the process of allowing bare graphic filenames, we have lost
the ability to
properly generate ._gray_.tex with the filenames rewritten to ._gray_. I'm
working on it.
Original comment by shiblon
on 11 Mar 2010 at 2:49
CRAP. This is hard.
So, graphicx sees ._gray_ at the end of the filename and barfs because it
doesn't know
the extension. If I add .pdf to the end of it to force the issue, then the
dependency
problem rears its ugly head again. There is no way to win this one with
pdflatex easily.
I can't change it to be something like __gray_ (instead of ._gray_) because
then the %.
matching rules don't work properly. I am welcoming any suggestions at this
point.
Original comment by shiblon
on 11 Mar 2010 at 3:21
OK - fixed. Miraculously.
r32cccde058e3 has the fix. Or you can pull from the tip.
Note that I had to change it from using ._gray_ to __gray_ (double underscore
at the
beginning). This is configurable with the GRAY_INFIX variable.
Original comment by shiblon
on 11 Mar 2010 at 3:43
I was able to make a grayscale figure by making "figure1__gray_.pdf". However,
I
wasn't able to do the whole document:
amcnabb@prodigy:~/clone/docs/thesis% make thesis__gray_.pdf
NOTE: You may ignore warnings about the following files:
thesis__gray_.d
Makefile:2051: thesis__gray_.d: No such file or directory
make: *** No rule to make target `thesis__gray_.d'. Stop.
amcnabb@prodigy:~/clone/docs/thesis%
I tried to do a log with VERBOSE=1, but it didn't give any additional
information.
And totally bikeshedding here, but the asymmetricity of the name is a little
rough
for me. Would you consider having GRAY_INFIX default to __gray? This would
make it
thesis__gray.pdf, which I think would be easier for me to remember. If you
hate the
idea, I would probably rather use your default than to set my own GRAY_INFIX.
Original comment by amcna...@gmail.com
on 11 Mar 2010 at 9:06
Ping me off list about this - maybe I can pull your thesis and try building it.
Original comment by shiblon
on 11 Mar 2010 at 9:12
It appears that building thesis__gray_.pdf works as long as I have already
built
thesis.pdf. The problem only occurs if I build thesis__gray_.pdf in a clean
directory. I don't know the Makefile as well as I should, but it looks like
the rule
"thesis.d thesis.tex --> thesis__gray_.tex" can't occur in the __gray_ case
because
"thesis.d" doesn't exist.
Would it be possible to fix this by making making thesis__gray_.d depend on the
rule
that creates thesis.d?
Original comment by amcna...@gmail.com
on 11 Mar 2010 at 11:52
What's confusing is that it is working for me. Did you pull from the tip?
The normal procedure is this:
file__gray.pdf is handled by this rule:
%.$(build_target_extension): %.bbl %.aux
That searches all the way down the dependency path until it finds that it needs
file__gray.tex, which depends on file.d and file.tex
file.tex is already there, but file.d is not, so it runs pdflatex to generate
it (look for a
comment that says "Behavior:" and you'll find the right section)
So, file.d is generated. Then the rule to generated file__gray.tex runs
because its
dependencies are now met.
Then the rest of the build process is exactly as though file__gray.tex had
already
existed on the system: dependencies are generated from it and stuff
(supposedly)
just builds.
I'm looking into this, but I'm very confused. There must be a subtle bug
somewhere.
file__gray.tex comes from file.d and file.tex
file.d isn't there, so it is built from file.tex by running pdflatex once
Original comment by shiblon
on 12 Mar 2010 at 1:48
I've definitely been on tip (but it never hurts to ask).
For some reason, it makes file.d when building file.pdf but not when building
file__gray.pdf. Maybe there's something subtle like it's trying to build
file__gray.d before file.d or something like that (?). If I manually do "make
file.d", then a subsequent "make file__gray.pdf" succeeds.
Original comment by amcna...@gmail.com
on 12 Mar 2010 at 4:44
Hmm. I noticed the following rule:
%.d %.aux %.aux.make %.fls: %.tex
This means that file__gray.d depends on file__gray.tex, as it should. But
somehow
there's a circular dependency making file__gray.tex depend on file__gray.d,
which
it shouldn't. The file__gray.tex file should depend on file.d but not
file__gray.d, right?
I don't know. Make confuses me, so maybe I have it all wrong. :)
Original comment by amcna...@gmail.com
on 12 Mar 2010 at 4:57
I don't know if this is related or not, but it seems really weird. If I do
"make
file.tex", I would expect it to quit since file.tex already exists and is not a
generated file. However, it instead runs pdflatex and builds the graphics.
Isn't
that a little odd?
Original comment by amcna...@gmail.com
on 12 Mar 2010 at 5:04
OK - this is bizarre. It generates the thesis__gray.d file on my system, same
files, but
not on yours. Looking into it. Weird, weird, weird.
Original comment by shiblon
on 12 Mar 2010 at 5:22
What I don't get is this: on my system, it has no trouble with the circular
dependency
(the nature of it is now obvious to me):
thesis__gray.tex: thesis.d thesis.tex
thesis.d: thesis.tex
BUT, and here's what it seems is happening: if you "include" the thesis__gray.d
file,
which we do automatically, it then tries to build thesis__gray.d, and we have
this
problem:
thesis__gray.d: thesis__gray.tex
But we're trying to build thesis__gray.tex in the first place. Yuck. I'm not
sure how
to solve this one. It works on my system, darn it!
Original comment by shiblon
on 12 Mar 2010 at 5:43
So, just to be clear, grayscale still works, but you have to apply it globally,
e.g.,
make GRAY=1 thesis.pdf
Then the output will be grayscale. At this point, I think that's the *only*
way I can
sanely support it anymore. The feature with the magic filenames was always
very
brittle, and now it's finally broken. To that, I say "good riddance".
I'm going to rip it out and submit a revision with it gone. The GRAY=1 will
still work,
though.
Original comment by shiblon
on 12 Mar 2010 at 6:02
r88004880caad rips the magic suffix out. I'm going to mark this "fixed" (there
is
some irony, there, especially if you think of it in terms of pets).
The downside to GRAY=1 is, naturally, that you have to make clean before using
it.
That means that things are slower. Sorry :(.
I imagine, but obviously could be wrong, that grayscale is really only needed
near the
end of a paper's build life. Most edits can be made in the color version.
Or, you can always create a Makefile.ini and set GRAY=1 in there. Then you'll
always
be working in grayscale.
Original comment by shiblon
on 12 Mar 2010 at 6:12
Reopening this issue, since I think it is related to issue 70, and that may
make this work
properly again. It's worth trying.
Original comment by shiblon
on 16 Mar 2010 at 4:48
I patched magic suffix stuff back in to r3145f63058e3. It's the current tip -
please give
it a try.
Original comment by shiblon
on 16 Mar 2010 at 6:13
Unfortunately, I'm still getting the "No rule to make target `thesis__gray.d`"
error.
Thank you for trying to fix it, but it looks like it still just doesn't want to
work.
Original comment by amcna...@gmail.com
on 16 Mar 2010 at 7:08
Weirdly, if you say "make thesis__gray.tex" first, everything works fine.
It seems like there should be a way to make this work. I'm looking over the
dependency
resolution now.
Original comment by shiblon
on 16 Mar 2010 at 7:26
I've figured out what is causing this. It's pretty tricky, unfortunately.
The problem can be boiled down thusly:
thesis__gray.d needs thesis__gray.tex (rule: %.d: %.tex)
thesis__gray.tex needs thesis.d (rule: %__gray.tex: %.d)
thesis.d needs thesis.tex (rule: %.d: %.tex -- oops -
make thinks this is
a repeat, which is wrong, but there you have it)
I can fix this by using static pattern matching, but now I'm getting different
errors.
I'll keep poking at it for a bit.
Original comment by shiblon
on 16 Mar 2010 at 8:14
I had noticed this, too, but I could never quite figure out why it thinks
thesis.tex
is a repeat. It seems like it should be clear that thesis.tex and
thesis__gray.tex
are completely different files. Crazy stuff. I admire your patience. :)
Original comment by amcna...@gmail.com
on 16 Mar 2010 at 8:35
Giving up again - in order to fix this properly, many deep changes are
required, and it's
very subtle. I almost had it, but it broke everything else :-/
For the foreseeable future, the way to go is
make clean
make GRAY=1
Original comment by shiblon
on 16 Mar 2010 at 10:34
Original issue reported on code.google.com by
amcna...@gmail.com
on 10 Mar 2010 at 9:32Attachments: