"clean" doesn't remove all the generated files

[shiblon]

Originally reported on Google Code with ID 87

I have a main .tex file and a number of .eps figures. The build process generates .pdf
and .eps.log intermediate files for each EPS figure, but the clean process doesn't
remove them.

Reported by stefan.bucur on 2010-06-27 13:54:39

[shiblon]

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?

Reported by shiblon on 2010-06-29 19:28:58

[shiblon]

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!

Reported by stefan.bucur on 2010-06-30 10:06:49

[shiblon]

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)

Reported by stefan.bucur on 2010-06-30 10:09:42

[shiblon]

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.

Reported by shiblon on 2010-06-30 12:43:49

[shiblon]

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.

Reported by stefan.bucur on 2010-06-30 13:20:08

---

• Attachment: test.tar.gz

[shiblon]

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.

Reported by shiblon on 2010-07-28 14:28:46

[shiblon]

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

Reported by draifen on 2010-10-12 17:03:15

[shiblon]

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.

Reported by shiblon on 2010-11-11 15:17:31

• Status changed: WontFix

[shiblon]

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.

Reported by jhcoppin on 2011-11-01 16:53:50

[shiblon]

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.

Reported by shiblon on 2011-11-01 17:21:37