dvadura@watdragon.waterloo.edu (Dennis Vadura) (06/30/91)
Submitted-by: Dennis Vadura <dvadura@watdragon.waterloo.edu>
Posting-number: Volume 20, Issue 76
Archive-name: dmake/patch02a
Patch-To: dmake: Volume 19, Issue 22-58
DMAKE 3.7 PATCH #2
------------------
Priority: Medium
Prerequisite: dmake 3.7 patch level 1 full distribution.
Location: You can obtain a copy of the patch from watmsg.uwaterloo.edu
via anonymous ftp from the directory pub/dmake. The file is
dmake37-patch2.Z. The patch is also submitted for posting
to comp.sources.misc.
Application: Change directory to the source directory containing the
dmake sources and run the patch through /bin/sh. It constructs
any required subdirectories and applies the patch program as
needed to apply patches to files. If you obtain the patch
files from a news group then you must first build the patch
source by running all parts of the patch through unshar or
/bin/sh.
Acknowledgment: Thanks to everyone who wrote with suggestions or bug fixes.
In most cases your fixes and/or suggestions were
incorporated into the sources. Your continued input makes
dmake a better tool.
DETAILS OF FIXES:
-----------------
- Fixed a bug in function.c. If you used a $(shell ...) macro in a line
which got expanded from within the input buffer Buffer (eg. in a rule
definition) nasty things could happen since _exec_shell re-used Buffer
when it shouldn't have.
- Made sure that -v and -n flags do not take effect across a $(shell ...)
macro expansion. This ensures that $(shell ...) recipes are always
executed when the macro is expanded and never contain noise from a -v
flag. Dunno how I missed this the first time around.
- Fixed a bug that set Current_target to NULL when making successive recipe
lines individually. This meant that temp files were being deleted late,
possibly from the wrong places, and hence not deleted at all.
- Fixed several inference bugs. Nothing too major:
1. a recipe of the form
%.foo:
@[
stuff ...
]
didn't get the group recipe attribute attached to the %.foo node
so when the inference algorithm was run it failed to attach the
correct attribute to go along with the new recipe.
2. Inference algorithm now marks for REMOVAL, ALL intermediate nodes
(it did this before too -- but by luck), and marks ALL nodes as
TARGETS, and all but the first node as being INFERRED. I doubt
that anyone will notice these changes. I had to have a really
screwy makefile to find the bug.
- Fixed $(shell ...) macro so that it can be nested to arbitrary depths.
It uses a single temporary file for the purpose and keeps reusing it for
each nested instance. Works like a charm.
- Fixed bug in rulparse.c where an attribute flag variable was of type
int and not t_attr as it should be. This caused problems on 16-bit
machines (reported by lots of people).
- Fixed a bug reported by paul@halserv2.hal.com, dmake.c line 373, would
dereference a NULL pointer if the hash table didn't contain an entry.
- Fixed a bug reported by paul@halserv2.hal.com, rulparse.c line 949
would dereference a NULL pointer if it tried to match a certain sequence
of %-meta rules.
- Fixed a bug reported by paul@halserv2.hal.com, make.c, the SET_TOKEN
call was getting called with a NULL pointer.
- Minor tweaks to the OS/2 scripts as reported by Frank Waley. Should make
MSC compiles work now.
- Changed sysvr4/stdarg.h to ensure that va_dcl is defined.
- Modified man page. The diffs would have been bigger than the source so
I just included new copies.
DETAILS OF ADDITIONS/CHANGES:
-----------------------------
- Added a sysvr3/pwd directory along with getcwd.c. The reason for this
addition is to hopefully eliminate once and for all the annoying
"lost a child" bug. If you see this bug appear then remake dmake with
make sysvr3pwd
or make xenixpwd
Both create a version of dmake that uses a local version of getcwd rather
than the C-library version. Thanks to Gwyn Dyer for providing the code
to getcwd.c. I used his version as it compiled on a xenix machine and
seemed to be the more widely used one. Thanks to all that sent me copies
of it. I hope this gets rid of the lost child issue once and for all.
- The MSDOS version now behaves identically to the UNIX versions when
running recipes containing embedded cd calls. I changed dmake to restore
the directory it was in prior to invoking a child process.
The following recipe will now behave identically under UNIX and DOS
all:
cd foo; make ...
cd fee; make ...
Previously to this change, the DOS version of DMAKE would have been in
the foo directory after the first line of the recipe, and would not
find fee.
- Added the -B flag. This is in response to several requests at supporting
spaces in front of recipe lines. This does not come without a price.
By default the flag is off and tabs are required to start recipe lines
unless it is a group recipe. If you turn the flag on, either through
supplying -B on the command line or by putting ".NOTABS := y" in the
makefile then when dmake scans non-group recipes they are terminated at
the first line that is only white space or contains no leading white space
and is either a macro definition or a rule definition.
Consider the following makefile:
all:
<tab> echo hi there
<space>echo e:test
<tab> echo hello
By default the recipe for all is simply: "echo hi there", and the remaining
two lines are parsed as a new rule definition with the associated recipe
being "echo hello". If you supply -B, then the recipe for 'all' is all
three lines above, since the second recipe line now begins with a space.
If you change the makefile to contain:
all:
<tab> echo hi there
<space>echo e:test
<tab> echo hi there
then the -B flag has no visible effect. The makefile is parsed the
same in both cases as the first recipe is terminated by the empty line.
or a valid recipe rule.
If you now change the makefile to contain:
all:
<tab> echo hi there
<tab> echo e:test
<tab> echo hi there
then by default all three lines form the recipe for 'all'.
Specifying -B terminates the first recipe after the first line and begins
a new rule definition with the line "echo e:test".
In summary:
By default: (no -B) a recipe is terminated by a line containing some
text that does not begin with a <tab>.
Specify -B: A recipe is terminated by a line that is only white space
or by a line containg text that contains NO leading
white space.
You can use the .NOTABS macro to set/reset this behaviour at will from
within a makefile. See the man page.
- Added OSRELEASE=coherent targets and directories to support Coherent
systems. Patches provided by David Fenyes (dfenyes@thesis1.med.uth.tmc.edu).
- Added OSRELEASE=msdos OSENVIRONMENT=ztcdos targets and directories to
support making of dmake using Zortech C++ 2.1. Patches provided by
David Engel (ods@utdallas.edu).
--
Kent Landfield INTERNET: kent@sparky.IMD.Sterling.COM
Sterling Software, IMD UUCP: uunet!sparky!kent
Phone: (402) 291-8300 FAX: (402) 291-4362
Please send comp.sources.misc-related mail to kent@uunet.uu.net.