Closed GoogleCodeExporter closed 9 years ago
Would you do me a favor and attach a minimal tarball of files that cause this
failure? I can try to reproduce on my end (and I will), but that will ensure
that I am actually tackling the right problem when I work on this.
Now, to make sure that I understand how to reproduce this, is this the right
sequence?
Create a blah.eps file that stands alone (not adjacent to a different source
file that compiles to .eps)
Problem 1:
- Run make on the including source document
- Note that blah.pdf does not get included (but does get created?)
- Run make again
- Note that all is well
For the above problem, I suspect that the .d file is not getting generated
correctly, and not triggering a rebuild of the .tex file after the graphics are
created, then the error coloring code runs on the first log file and notes that
there was a missing graphic (which it already knew in order to build it). What
it really should do is run pdflatex again.
Problem 2:
- Run make "blah.pdf"
- Run make clean
- Note that blah.pdf didn't go away.
I think this is due to .eps not being properly marked as a source file type.
It's a tricky issue, so I'm not yet sure about that.
Original comment by shiblon
on 26 Dec 2010 at 7:26
thanks for looking into this.
I attached an example tarball which would cause the issue.
I logged the commands in README.
And for the problem 2, I notice that, upon the first fresh make,
the .d file would contain the following entry for each of the eps figure.
"-include fig/test1.gpi.d"
However, after the first make,
the new generated .d file would contain only ONE such entry for the last
included eps figure.
And I think this is the reason why that the updated eps do not get re-converted.
Original comment by payne.ch...@gmail.com
on 27 Dec 2010 at 3:15
Attachments:
Oh, you have figures in subdirectories? That's not supported by the makefile,
and never will be. I suspect that if you were to move things into the same
directory, it would start working (at least better than it is now).
Original comment by shiblon
on 31 Dec 2010 at 7:43
This might work better with the changes related to issue 100. Can you take a
look at the revision listed there and see if your problems are fixed? I think
the problems are related.
Original comment by shiblon
on 1 Jan 2011 at 12:15
The latest fix of issue100 doesn't seem to solve my problem.
But I agree that this one looks highly related to issue100, and maybe some more
tweaks would be needed to capture the latex error.
And, the problem persists without putting figures in subdirectories.
I've just attached another tarball.
Original comment by payne.ch...@gmail.com
on 1 Jan 2011 at 2:09
Attachments:
I have fixed the clean issue, and am now working on the build failure.
rddbeeae3f23c
Original comment by shiblon
on 4 Jan 2011 at 2:59
And now, the failure to rebuild after creating test1.pdf and test2.pdf is
fixed. r07ee69208eac should do it.
That was a subtle one where the difference between pdflatex and latex messed up
my previous latex-oriented logic.
For the failure to properly clean out .pdf files and .log files (you can remove
your Makefile.ini, now), the problem was a lack of stated support for .eps
source files. You could have fixed that by gzipping them, but now it should
work properly.
For the failure to call pdflatex after graphics were created, the problem was
caused by a deep assumption made about latex's behavior when graphics files are
missing. When producing a .dvi file, latex will go ahead and do that even if
it can't find any graphics that it needs. pdflatex, however, will fail to
produce a .pdf if there are missing graphics. I wasn't handling the missing
file properly and it broke my logic. That should be fixed, now.
Both of your issues have now been addressed. Feel free to either verify or
reopen this bug if that is not the case. I'm probably going to upload a new
version, soon, but I've attached the new Makefile here for you to try out first.
Original comment by shiblon
on 4 Jan 2011 at 3:38
Attachments:
Thanks!
The fix works great for issue1.
I found that there is a remaining problem for issue2,
caused by the file "get-graphics.sed".
There is a code segment like the following,
to extract the graphic entries from the log.
------------------------------------
/.*File: \(.*\) Graphic file (type [^)]*).*/{
s//\1/
b addtargets
}
------------------------------------
The code works if there is only one file entry in each paragraph,
but this is not mostly true.
In my previous attached example, there exist multiple entries in the same
paragraph.
And thus the previous greedy regx would only match the last file: test3.pdf.
That means, changes to test1.eps or test2.eps would not trigger the rebuild.
------------------------------------
File: test1.pdf Graphic file (type pdf)
<use test1.pdf> <test2.pdf, id=2, 344.28625pt x 212.795pt>
File: test2.pdf Graphic file (type pdf)
<use test2.pdf> <test3.pdf, id=3, 344.28625pt x 212.795pt>
File: test3.pdf Graphic file (type pdf)
<use test3.pdf> <test4.pdf, id=4, 344.28625pt x 212.795pt>
------------------------------------
I fixed this by using loops to extract multiple entries within one paragraph,
and output one target per entry.
The updated file is attached here, but I am no doubt a sed newbie.
So you would know better how to address this.
Original comment by payne.ch...@gmail.com
on 5 Jan 2011 at 12:47
Attachments:
Oh, fascinating! I'll work on this tomorrow (if I forget, please feel free to
pester me - this is an important issue).
Original comment by shiblon
on 5 Jan 2011 at 1:26
Would you do me a favor and send me the minimal .tex file that generates this
log? I'd like to add a regression test for this and am having a hard time
reproducing it.
Original comment by shiblon
on 5 Jan 2011 at 2:36
By the way, that's a very nice sed patch. Not bad for a self-proclaimed newbie
:-)
You must be using GNU sed, though. I see things like [^\n], which doesn't work
in BSD sed. There are other things in there, too, that don't work for BSD sed,
so I'm going to have to hack at it a bit. I'm sorry about that, and hope you
don't mind the hack job it's about to get.
Original comment by shiblon
on 5 Jan 2011 at 2:42
Never mind about the minimal case. I get it, now. Boy, it's been a while.
So, here's what happens. get-graphics detects graphics in two cases: missing
graphics files and existing graphics files (since no matter when make runs, we
need to know whether to rebuild because a file *changed*, not just because it
isn't there anymore).
Thanks very much for the patch. Now that I have a log file to work with, I
should be able to easily reproduce this and get a fix that works properly.
Original comment by shiblon
on 5 Jan 2011 at 2:51
I found a very simple patch that will fix this. Check it out.
Original comment by shiblon
on 5 Jan 2011 at 3:59
Attachments:
I found an even simpler patch and commited r9eca3daadc0e . Marking fixed.
Feel free to reopen if it doesn't work for you.
This is the last big blocking issue that I know of for releasing a new rc
download. If you verify this, I'll upload a new rc.
Original comment by shiblon
on 5 Jan 2011 at 4:08
Ah... really an elegant fix.
Thanks! it works like a charm finally.
Original comment by payne.ch...@gmail.com
on 5 Jan 2011 at 9:46
Original comment by shiblon
on 6 Jan 2011 at 8:28
Original issue reported on code.google.com by
payne.ch...@gmail.com
on 25 Dec 2010 at 11:28