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.
gjh@hplb.hpl.hp.com (Graham Higgins) (06/18/91)
I wouldn't bother to upload the uni-sb stuff to A.A. There has been some divergence of philosophy between a.a. and uni-db.de (UNIXMODE mainly). I had most of this code (cat as well) and eventually deleted it in favour of currently-supported GNU s/w. The code at uni-sb.de is mostly binaries with very little sources, due the porter's lack of immediate access to the uni-sb machine. This is one of the reasons I wanted to put together a complete and up-to-date GNU suite on A.A. Yes, uni-sb.de Make will probably want UNIXMODE setting. It is also possible that you might have to remove the file extensions from your executables, Edgar Roeder pursued bash for a while and it stems from this. Why don't you try jrb's pdmake? One day real soon now I'll post the make 3.58 which I have been using without problems under Mint v7 (anyone else found Mint v8 to be somewhat flaky?) to compile the GCC 1.40 libraries and utilities on my 4080STFM. 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. ------------------------------------------------------------------
avgroeni@cs.ruu.nl (Annius Groenink) (06/19/91)
In <GJH.91Jun18164837@ghiggins.hpl.hp.com> gjh@hplb.hpl.hp.com (Graham Higgins) writes: >my 4080STFM. You mean 4160. > >Graham The formula is: {# of Kilobytes} * (520/512) -- ________________________________________________________ Annius Groenink|undergraduate student Laan van Borgele 24|maths/computer science at the 7415 DJ Deventer|University of Utrecht, Holland.
gjh@hplb.hpl.hp.com (Graham Higgins) (06/20/91)
++ >my 4080STFM. ++ ++ You mean 4160. You ain't seen my soldering :-)