When there is nothing to do, sometimes output sometimes not

[GoogleCodeExporter]

What steps will reproduce the problem?

Run make with no arguments multiple times in a row (without changing any source 
files).

Unfortunately, I am not sure the precise series of steps required. I notice 
this happening semi-
randomly, but presumably it is related to the state of the set of auxiliary 
files created by TeX.

What is the expected output? What do you see instead?

In the case where no source files have changed, sometimes make produces no 
output at all, 
other times it outputs "make: Nothing to be done for `all'." It would be nice 
if make always 
produced no output in this circumstance, or at least was consistent.

What version of the product are you using? On what operating system?

2.1.25 on Mac OS X 10.5.6

Please provide any additional information below.

Occasionally when I am doing copyediting on a LaTeX file, I like to run the 
makefile in a loop 
from my shell (with a "sleep 3" or something thrown in). Then I can make a 
change in my .tex 
file, save it, and within a few seconds see the PDF updated. When make outputs 
the "Nothing to 
be done" message, it just fills up my Terminal window. No biggie, but kinda 
annoying.

Original issue reported on code.google.com by rbre...@gmail.com on 22 Apr 2009 at 4:43

[GoogleCodeExporter]

This is a known and long-standing issue.  I have yet to find a solution for it.

Incidentally, if I could make it work properly, it would *always* output 
"Nothing to
be done for 'all'."  The bug is that it sometimes does not output that when 
there's
nothing to be done.

The message comes from "make" and means that it didn't find any need to rebuild
anything.  When that message does not appear, it means that it erroneously 
found work
to do.  So, fixing this bug properly might actually make you sadder, not 
happier ;-)

Original comment by shiblon on 1 May 2009 at 1:57

[GoogleCodeExporter]

Bummer. I have just discovered "make -q", which allows me to not produce output 
unless there is something 
to be done, so I'm OK with the output now :)

Unfortunately, the bug prevents my little script from working properly:

#!/bin/sh

# Loop forever
while [ 1 ]
do
    # Is there work to be done?
    if ( ! make -q );
    then
        # If so, do work and display resulting PDF
        make show
    fi
    # Give CPU a rest
    sleep 2
done

When make is finding work to be done when there isn't any, make -q returns 1 
and thus my PDF viewer pops 
up every 2 seconds. Is there anything I can do to help track down this bug? 
Should I save a copy of my files 
when it is working properly and another when it isn't?

Thanks.

Original comment by rbre...@gmail.com on 1 May 2009 at 7:25

[GoogleCodeExporter]

There may be something you can do to help track it down.  The Makefile has a few
modes that help with debugging.  For example, you might invoke it thus inside 
of your
loop (in bash):

echo >> output_log "-- RUNNING MAKE --"
make -q SHELL_DEBUG=1 VERBOSE=1 all >> output_log 2>&1

Then you get a large bunch of spew that may possibly be meaningful for me.

You might try it without SHELL_DEBUG (or even VERBOSE) enabled first, but use 
the
'-d' flag.  What's mostly interesting is make's own verbose output, which tells 
what
kinds of dependencies it thinks are not built.  It's hard to read, though.

I guess, in conclusion, that there are a few things that might help.  First, 
just run
it with make's own verbose mode (-d) - that tells what dependencies it thinks 
it has.
 Then, try running it without -d, but with the SHELL_DEBUG and VERBOSE parameters
above if -d isn't helpful.

I apologize for putting some of the debugging on you.  I haven't actually used 
the
makefile in a while, at least not heavily, so it's a bit harder for me to 
produce
good input for debugging.

Original comment by shiblon on 1 May 2009 at 8:07

[GoogleCodeExporter]

Just finished my last paper of the semester, and took some debugging 
information. In the course of editing a 
single .tex file, after the initial make following saving the file sometimes I 
would get the "make: Nothing to be 
done for `all'." and other times no output. I diffed the make -d output for two 
runs, the first producing the 
correct output, and the second producing no output. The only change between the 
runs was editing the file 
assignment-3.tex.

Diff from correct run:

           Prerequisite `assignment-3.aux.make' is older than target `assignment-3.auxbbl.make'.
          No need to remake target `assignment-3.auxbbl.make'.

Diff from incorrect run:

           Prerequisite `assignment-3.aux.make' is newer than target `assignment-3.auxbbl.make'.
          Must remake target `assignment-3.auxbbl.make'.
Putting child 0x00418c70 (assignment-3.auxbbl.make) PID 16398 on the chain.
Live child 0x00418c70 (assignment-3.auxbbl.make) PID 16398 
Reaping winning child 0x00418c70 PID 16398 
Removing child 0x00418c70 PID 16398 from chain.
          Successfully remade target file `assignment-3.auxbbl.make'.

With SHELL_DEBUG=1 and VERBOSE=1 turned on, the only difference is that for the 
incorrect output run I get:

    sed -e '/^\\newlabel/d' assignment-3.aux.make > assignment-3.auxbbl.make.temp; \
    ! diff -q 'assignment-3.auxbbl.make.temp' 'assignment-3.auxbbl.make' >/dev/null 2>&1 && mv -f 
'assignment-3.auxbbl.make.temp' 'assignment-3.auxbbl.make' || :

Note that the in either case it seems to stay stuck in one mode (correct output 
or no output at all) across 
multiple make runs as long as no files are changed. I'm not sure what triggers 
the change precisely, in my 
experience it can be triggered by just editing some text in the .tex file, but 
of course that could trigger changes 
in the auxiliary files.

I hope this helps track down the problem. Let me know if there is more 
debugging output that would be helpful.

Original comment by rbre...@gmail.com on 15 May 2009 at 8:45

[GoogleCodeExporter]

Okay, that *is* interesting.  And not terribly surprising.  Dealing with 
automatic
bib generation is the messiest part of the whole makefile.  I had a beautiful,
elegant solution in place, then I started messing with bib files and basically 
had to
rewrite all of the core logic from scratch :-p

So, that helps.  I'll take a hard look at it and see what I can find.  No 
guarantees
of success, though.

Original comment by shiblon on 15 May 2009 at 8:57

• Changed state: Accepted

[GoogleCodeExporter]

Sorry I'm so slow to respond - life is busy.

That does look like very useful debugging output.  Thanks for thinking of 
boiling it
down with a diff.  That was a great idea.  I'll take a look and see what I can 
find.

Original comment by shiblon on 26 May 2009 at 3:35

[GoogleCodeExporter]

Sorry I haven't looked at this yet.  Being a lone project maintainer has its 
disadvantages 
:(

I just wanted you to know that I'm still here.  Feel free to ping the bug and 
generally 
become a nuisance if I don't get to it fast enough.

Original comment by shiblon on 19 Jun 2009 at 2:38

[GoogleCodeExporter]

No problem, and no need to feel guilty about not having time to work on this 
volunteer project! :) Fixing it would 
make for a small improvement in my copy editing process, but it's not holding 
me back in any real way. Thanks 
again for all your hard work on the makefile.

Original comment by rbre...@gmail.com on 19 Jun 2009 at 7:39

[GoogleCodeExporter]

I think I'm going to mark this WontFix for now.  I suspect that it has 
something to do 
with the way that the aux file changes in the presence of bibliography stuff, 
and it's not 
something I have energy to track down right now :-(.  If the priority of this 
increases, 
just let me know and we'll reopen the bug and really try to track it down.

Thanks for the report, and sorry I can't get to it?

Original comment by shiblon on 19 Nov 2009 at 7:32

• Changed state: WontFix

[GoogleCodeExporter]

That's a bummer, but I understand completely.

Original comment by rbre...@gmail.com on 19 Nov 2009 at 7:40