"clean" doesn't remove all the generated files

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by stefan.b...@gmail.com on 27 Jun 2010 at 1:54

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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:

• test.tar.gz

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

• Changed state: WontFix

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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