Closed GoogleCodeExporter closed 9 years ago
This works for me. A couple of questions:
1) What version of the makefile are you using?
2) Are any of your graphics in subdirectories?
Original comment by shiblon
on 29 Jun 2010 at 7:28
OK, I apologize for the lack of details. I had the impression this was not
implemented at all. So here it goes:
1) I'm using the latest version as of now: 2.2.0-rc2.
2) All my graphics are in the same directory as the .tex file.
Other relevant details:
3) The code that includes the graphics is of form:
\begin{figure}[h!]
\centering
\epsfig{file=name, width=3in}
\caption{Caption}
\label{fig:name}
\end{figure}
4) I'm using the new build system, that invokes pdflatex.
5) For each figure, a .eps.cookie file is generated as well, but this one is
removed by the clean target.
Please let me know if you need any more information. Thanks for your quick
reply!
Original comment by stefan.b...@gmail.com
on 30 Jun 2010 at 10:06
Another detail that may be of interest: The Makefile is located in a different
directory (as a common Makefile for all my projects), and it is included by
another Makefile in the current directory, like this:
onlysources.tex := main.tex
# The location of the main Makefile
LATEX_MAKEFILE := ../../common/Makefile.common
include $(LATEX_MAKEFILE)
Original comment by stefan.b...@gmail.com
on 30 Jun 2010 at 10:09
Would it be possible to attach a minimal example of the problem files to this
bug? Also, you should probably consider switching away from epsfig and using
\includegraphics (from the graphicx package) instead.
Frankly, I'm surprised that epsfig is working for you, considering that you are
now building with pdflatex using 2.2.0-rc2... pdflatex doesn't support direct
inclusion of eps graphics.
Original comment by shiblon
on 30 Jun 2010 at 12:43
Here is a minimal setup that exhibits the problem - it looks that somehow
pdflatex manages to work with epsfig... However, if you remove the bibliography
from the .tex file, the build process breaks with the following error:
$ make
NOTE: You may ignore warnings about the following files:
test.d
Makefile:2217: test.d: No such file or directory
= test.tex --> test.d test.pdf.1st.make (0-1) =
= test.tex --> test.d test.pdf.1st.make (1-1) =
= circle.eps --> circle.pdf =
mv: rename test.pdf.1st.make to test.pdf: No such file or directory
LaTeX Error: File `circle' not found.
This error does not manifest when the document has bibliography (and thus
requires an additional pass).
In both cases, however, the clean target doesn't remove circle.eps.log and
circle.pdf.
Original comment by stefan.b...@gmail.com
on 30 Jun 2010 at 1:20
Attachments:
Sorry it took so long to reply. Work took over :)
So, does this error still happen if you change to using graphix and
includegraphics? If not, I'm going to put it on the back burner for a while,
since I'm sort of swamped at work at the moment. If it is still broken, I'll
bump it up in priority as best I can.
Original comment by shiblon
on 28 Jul 2010 at 2:28
I can confirm this bug, and maybe give a little more info. When I start with a
.gpi file, the makefile will generate a .eps file, then a .pdf, and put it into
the result. Make clean will then remove everything (except the .gpi) as
expected. However, when the original graphic image is .eps, the makefile will
create .eps.log and .pdf files that are not removed by make clean. I have seen
this every time I start with an eps as the original image file, invariably.
The version that I have is 2.2.0-beta8. I use the graphicx package and include
the image with \includegraphics. My guess is that it thinks that a .eps is an
intermediate file and doesn't find what it thinks is an original, so it doesn't
delete any of the derivatives of the .eps. Let me know if I can give you more
information.
Matt
Original comment by drai...@gmail.com
on 12 Oct 2010 at 5:03
Ah, I see what's going on here, and off the top of my head, I can't see an easy
fix.
The logic for determining which files should be kept and which should be
cleaned is based on the distinction between "source file" and "output file"
types. Since .eps can be both a source and an output, the logic can't tell
whether to remove it or not in all cases.
Given the way make works, and how intelligent it isn't, off the cuff this looks
like a really hard problem to solve (sort of like solving the "clean up stuff
in sub directories" problem). For now I'm marking it wontfix, and I do
sincerely apologize for that.
Original comment by shiblon
on 11 Nov 2010 at 3:17
I had this same problem. I circumvented it in the following way:
I added a rm $1.cookie $1.log at the bottom of the "define convert-eps-to-pdf"
routine so it reads as follows:
# $(call convert-eps-to-pdf,<eps file>,<pdf file>,[gray])
# Note that we don't use the --filter flag because it has trouble with bounding
boxes that way.
define convert-eps-to-pdf
$(if $3,$(CAT) '$1' | $(call kill-ps-color) > '$1.cookie',$(CP) '$1'
'$1.cookie'); \
$(EPSTOPDF) '$1.cookie' --outfile='$2' ; > $1.log; \
$(call colorize-epstopdf-errors,$1.log); \
rm $1.cookie $1.log
endef
This deletes the temporary files once they have been used. If the pdf versions
are up to date then the routine needs not be called.
Original comment by jhcop...@gmail.com
on 1 Nov 2011 at 4:53
That's an interesting idea, but it won't make it into the main source. The
problem is that the colorization is never going to be perfect, but often it at
least tells you that something is wrong. The .log file is always the canonical
place to go for that information.
Also, I'm not sure that it solves the problem, really. For example, .cookie
and .log files are *already* deleted in "make clean". If that isn't working,
it warrants its own issue and should be fixed.
Original comment by shiblon
on 1 Nov 2011 at 5:21
Original issue reported on code.google.com by
stefan.b...@gmail.com
on 27 Jun 2010 at 1:54