yochju / latex-makefile

Automatically exported from code.google.com/p/latex-makefile
Other
0 stars 0 forks source link

Muted "LaTeX Error" when the class file is missing #98

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
When a class file is missing, pdflatex reports the error as follows:

! LaTeX Error: File `IEEEtran.cls' not found.

However, this error is not being passed on by the Makefile, which instead 
reports:

% make
NOTE: You may ignore warnings about the following files:

     paper.d

Makefile:2265: paper.d: No such file or directory
= paper.tex --> paper.d paper.pdf.1st.make (0-1) =
make: *** [paper.d] Error 1
%

If it would be helpful, I could produce a minimal test case, but it's easy 
enough to make one by taking any latex file and replacing the document class 
with gibberish.

Original issue reported on code.google.com by amcna...@gmail.com on 4 Nov 2010 at 10:00

GoogleCodeExporter commented 9 years ago
By the way, I think the Makefile might be catching the "! LaTeX Error: File" 
and trying to find if there's a way to autogenerate the file, but when it 
realizes it can't do this, it just says "Error 1".  That's just an idea--I 
don't know if it's helpful.

Original comment by amcna...@gmail.com on 4 Nov 2010 at 10:02

GoogleCodeExporter commented 9 years ago
Yes, that's exactly what's happening.  What is confusing me is that you aren't 
getting a "no rule to build IEEEtran.cls" error, but an Error 1 instead.

Make really is supposed to report these better than it is.  I wonder what is 
going on.

I'll see if I can make a minimal test file to trigger this.

Original comment by shiblon on 5 Nov 2010 at 7:40

GoogleCodeExporter commented 9 years ago
Try rcf3fcf70a99e and see if that floats your boat.

Original comment by shiblon on 5 Nov 2010 at 8:21

GoogleCodeExporter commented 9 years ago
That seemed to do it.  By the way, will the fix work for missing graphics 
files, too?  I think I've occasionally run into the same error when there's a 
missing graphics file that can't be autocreated.

Anyway, for the .cls case, I can confirm that the problem is fixed.

Original comment by amcna...@gmail.com on 5 Nov 2010 at 8:31

GoogleCodeExporter commented 9 years ago
I'm not sure whether this will affect graphics that can't be built or not.  It 
seems like it *shouldn't*, but there is enough complexity here, and I'm far 
enough removed from using it, that I can't say for sure.

Speaking of which, this project needs another maintainer.  Volunteers?

Original comment by shiblon on 8 Nov 2010 at 5:35

GoogleCodeExporter commented 9 years ago
If it were in Python, I just might volunteer, but make makes my sed head hurt.  
I mean it makes my sad head hurt.  I think.

Original comment by amcna...@gmail.com on 8 Nov 2010 at 7:58

GoogleCodeExporter commented 9 years ago
I'm about >< this close to starting over in Python.  If only I had time to do 
that instead of fix bugs ;-)

I jest, of course.  Bugs are important, and I am going to fix them (someday).  
But, I would *love* to brainstorm with you about how a Python version would 
look, especially since you are deep into using it right now.  If you have some 
time for a chat sometime, let's start that project.  It would be fun.

Meanwhile, I'm going to leave this bug closed.  If you find it bites you again 
for other missing files, let's reopen it.

Original comment by shiblon on 11 Nov 2010 at 3:14

GoogleCodeExporter commented 9 years ago
I think that doing it in Python sounds fun.  I'm not sure where the dependency 
resolution stuff would come from (it would be nice if there were a 
well-maintained existing library that did this), and it would be nice to see 
what should or shouldn't be borrowed from Rubber.

Original comment by amcna...@gmail.com on 11 Nov 2010 at 5:47

GoogleCodeExporter commented 9 years ago
Cool.   Let's take this discussion out of the tracker, then, and see what we 
can come up with.

Original comment by shiblon on 11 Nov 2010 at 6:13

GoogleCodeExporter commented 9 years ago
I just had cause to use this and found that a *ton* of errors are passing 
silently, now.  As a result, I'm reopening this bug and have just finished a 
major code restructuring project to facilitate finding these issues.

There is no longer a "Makefile" in the source code, only a Makefile.in and a 
whole bunch of supporting bits and pieces.  Right now there are only a few 
things factored out, and most of them are .sed files.  To get the Makefile, 
just run "./build".

Now, to debug things like latex error output, you can just do

./run_sed.py colorize-latex-errors.sed yourtexfile.log

And it will show you what the sed script is doing.  You'll also notice that the 
sed script is actually a valid script, so you could *almost* just run it 
directly (it might not look quite right, but it will still give you a good idea 
of what's going on).

Anyway, take a look at the output of that with a broken log file.  It should 
help us to zero in on problems like these.

Original comment by shiblon on 22 Nov 2010 at 6:21

GoogleCodeExporter commented 9 years ago
By the way, I just pushed another tip.  I think this one works better.  Just 
update, ./build and give it a whirl.

In other excellent news, colorize-latex-errors.sed is now heavily, heavily 
commented, and should therefore be more accessible to mortals.  Doing this 
build step from source to create the makefile allows me to do that because it 
makes post-processing comments away possible.  Nifty.  Anyway, have a look, 
give run_sed.py a whirl, and let me know what errors you aren't finding in your 
log.

Original comment by shiblon on 23 Nov 2010 at 1:03

GoogleCodeExporter commented 9 years ago
Just to follow up with this, I believe that this issue is fully put to bed with 
the completion of issue 100.  As for redoing in Python, that still sounds fun, 
but at least we're making progress on things as they are.

Original comment by shiblon on 4 Jan 2011 at 3:40