This revealed another long standing problem with pmake's port to bsd.
.MAKE was not set as the manual page states. Set it and remove another
typo in my last commit.
Unfortunately this revealed a deeper problem with the brk_string code.
To fix it:
- remove sharing of the buffer between brk_string invocations
- change the semantics of brk_string so that the argument array
starts with 0, and return the buffer where the strings are
stored
Actually there were two bugs:
- Add REG_NOTBOL after the first substitution.
- Handle the rm_so == rm_eo == 0 case, where in a substitution such
as 's/bzzzt/z*/g' the first time z* matches nothing.
directory specified, and add it to sysIncPath only if it exists.
However, afterwards make tested for the presence of a -m option by
checking to see if sysIncPath was an empty list, and assumed that
the -m option was not used if it was empty. This obviously breaks
if -m specified a non-existent directory. So I have added a flag
that is set if the -m option is used, and I test that instead.
Make used to only use the search path for nodes that were pure
sources (not targets of other sources). This has been corrected
and now gnu-autoconf generated Makefiles work in directories other
than the source one.
- Suffix transformation rescanning:
Suffix transformations (.c.o:; cc ...) were only recognized in
the past when both suffixes were members of the suffix list.
Thus a sequence like:
.z.b:
echo ${.TARGET}
.SUFFIXES: .z
would cause .z.b: to be inserted as a regular target (and the main
target in this case). Other make programs always add rules that
start with a period in the transformation list and never consider
them as targets. We cannot do that (consider .depend files) so we
resort to scanning the list of the current targets every time a
suffix gets added, and we mutate existing targets that are now
valid transformation rules into transformation rules. If the
transformed target was also the main target, we set the main target
to be the next target in the targets list.
I.e. if you had a line in your Makefile:
../foo.o: foo.c
`..' would be added in the search path. The addition of such paths has
been now disabled. If a pathname contains a slash, then the directory
where such a file is found is not added to the search path. Of course
this eliminates most (all?) use of this function.
cgd