ralph@laas.fr (Ralph P. Sobek) (05/14/91)
I am trying to use GNU Make in order to control a LaTeX document. This is GNU make v. 3.54 that comes off of atari.archive. The same Makefile works on my Sun SPARC, but gives 2 bombs on my Mega 4 ST. The Makefile replaces .SUFFIXES to be LaTex/TeX specific. It also uses sub-directories: PARAGRAPHS = $(patsubst %,$(DIR_P)/%.tex, $(PARAGRAPHS_LIST)) The rule that GNU make has trouble with seems to be the following: %.bbl : %.bib $(DIR_P)/%.tex -bibtex $* if egrep -s "^(There were .* error messages)$$" $*.blg ; then \ touch $< ; fi $DIR_P has the value "acm". When GNU make is run with -d it sees that it should check in the subdirectory. But when wanting to do the implicit dependencies for foobar.bbl, which are foobar.bib and acm/foobar.tex, it tries also to look for either acm/SCCS/foobar.tex or acm/RCS/foobar.tex. Immediately: 2 bombs! Earlier, it checked for SCCS/foobar.tex and RCS/foobar.tex and coninued without aborting. The problem might be the double directory structure. Has anybody else used GNUMAKE for LaTeX and friends? Also, this GNUMAKE came with GCC 1.35 or 1.36. Maybe a more recent version is necessary. Thanks to all, -- Ralph P. Sobek Disclaimer: The above ruminations are my own. ralph@laas.fr Addresses are ordered by importance. ralph@laas.uucp, or ...!uunet!laas!ralph If all else fails, try: sobek@eclair.Berkeley.EDU =============================================================================== Proud owner of a Mega 4 ST. Wishing it was a Mega STe! :-|
ralph@laas.fr (Ralph P. Sobek) (05/16/91)
I received e-mail that stated that there might be an interaction between GNUMAKE and PINHEAD. So I deactivated PINHEAD, and the problem is identical. In this addendum I enclose the debug output for `gnumake -ndp -f makefile': # GNU Make version 3.54, by Richard Stallman and Roland McGrath. # Copyright (C) 1988, 1989 Free Software Foundation, Inc. # This is free software; see the source for copying conditions. # There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A # PARTICULAR PURPOSE. Reading makefiles... Updating makefiles.... Considering target file `makefile'. Looking for an implicit rule for `makefile'. Trying pattern rule with stem `makefile'. Trying implicit dependency `makefile,v'. Trying pattern rule with stem `makefile'. Trying implicit dependency `RCS/makefile,v'. Trying pattern rule with stem `makefile'. Trying implicit dependency `s.makefile'. Trying pattern rule with stem `makefile'. Trying implicit dependency `SCCS/s.makefile'. No implicit rule found for `makefile'. Finished dependencies of target file `makefile'. No need to remake target file `makefile'. Updating goal targets.... Considering target file `make'. File `make' does not exist. Considering target file `acm/planning.tex'. Looking for an implicit rule for `acm/planning.tex'. Trying pattern rule with stem `planning.tex'. Trying implicit dependency `acm/planning.tex,v'. Trying pattern rule with stem `planning.tex'. Trying implicit dependency `acm/RCS/planning.tex,v'. BOOM! BOOM!! Two bombs. Is there any way to disable the implicit rules for RCS and SCCS? Thanks! -- Ralph P. Sobek Disclaimer: The above ruminations are my own. ralph@laas.fr Addresses are ordered by importance. ralph@laas.uucp, or ...!uunet!laas!ralph If all else fails, try: sobek@eclair.Berkeley.EDU =============================================================================== Proud owner of a Mega 4 ST. Wishing it was a Mega STe! :-|
entropy@gnu.ai.mit.edu (maximum entropy) (05/16/91)
In article <RALPH.91May16153224@orion.laas.fr> ralph@laas.fr (Ralph P. Sobek) writes: >I received e-mail that stated that there might be an interaction >between GNUMAKE and PINHEAD. So I deactivated PINHEAD, and the >problem is identical. In this addendum I enclose the debug output for >`gnumake -ndp -f makefile': > [...deleted...] > Trying implicit dependency `acm/planning.tex,v'. > Trying pattern rule with stem `planning.tex'. > Trying implicit dependency `acm/RCS/planning.tex,v'. >BOOM! BOOM!! Two bombs. Is there any way to disable the implicit >rules for RCS and SCCS? I believe the problem is a memory leak somewhere. GNU Make seems to crash after I use it for a while, and the more memory I have available, the longer it takes. I haven't really tested this idea out scientifically, so it should be taken for what it is--pure speculation. In reality, the problem might be caused by something completely different. entropy -- entropy@gnu.ai.mit.edu entropy. . .it's not just a good idea, it's the second law. Boycott Lotus, Apple, Ashton-Tate and Xerox. Join the League for Programming Freedom! Write to league@prep.ai.mit.edu for more information.
gjh@hplb.hpl.hp.com (Graham Higgins) (05/17/91)
++ I believe the problem is a memory leak somewhere. GNU Make seems to ++ crash after I use it for a while, and the more memory I have ++ available, the longer it takes. I haven't really tested this idea out ++ scientifically, so it should be taken for what it is--pure ++ speculation. In reality, the problem might be caused by something ++ completely different. I *wondered* whether that was the problem I was getting, I checked ou the operation of GNUMake under Monitor and the problem seemed to be some interaction between the CLI (Edgar Roeder's Bash) and Gnumake and seemed to indicate problems with mshrink. I recompiled GNUMake for my own purposes, without a number of the search options (.F, etc) and removed the SCCS stuff, leaving in the RCS. I also used a different shell. The problem went away. I didn't follow it up. Graham ====== ------------------------------------------------------------------ Graham Higgins | gjh%ghiggins@hpl.hp.co.uk Hewlett-Packard Labs | gjh%ghiggins@hplb.hpl.hp.com Filton Road, Stoke Gifford | gjh%hplb.csnet@csnet-relay.arpa Bristol, U.K. | ...!mcvax!ukc!hplb!gjh Tel: +44 272 799910 x24014 Fax: +44 272 790554 ------------------------------------------------------------------ Disclaimer: My opinions above are exactly that, mine and opinions. ------------------------------------------------------------------
entropy@gnu.ai.mit.edu (maximum entropy) (05/18/91)
In article <GJH.91May17120413@ghiggins.hpl.hp.com> gjh@hplb.hpl.hp.com (Graham Higgins) writes: >I *wondered* whether that was the problem I was getting, I checked ou the >operation of GNUMake under Monitor and the problem seemed to be some >interaction between the CLI (Edgar Roeder's Bash) and Gnumake and seemed to >indicate problems with mshrink. >I recompiled GNUMake for my own purposes, without a number of the >search options (.F, etc) and removed the SCCS stuff, leaving in the RCS. I also >used a different shell. The problem went away. I didn't follow it up. Could you perhaps put your version on the terminator archive? (Or, mail it to me and I'll put it up, if you can't FTP.) Thanks, entropy -- entropy@gnu.ai.mit.edu entropy. . .it's not just a good idea, it's the second law. Boycott Lotus, Apple, Ashton-Tate and Xerox. Join the League for Programming Freedom! Write to league@prep.ai.mit.edu for more information.