cvs commit: src/usr.bin/make cond.c cond.h for.c for.h parse.c
parse.h
Harti Brandt
hartmut.brandt at dlr.de
Mon Apr 11 02:06:16 PDT 2005
On Mon, 11 Apr 2005, Kris Kennaway wrote:
KK>On Mon, Apr 11, 2005 at 07:20:10AM +0000, Hartmut Brandt wrote:
KK>> harti 2005-04-11 07:20:10 UTC
KK>>
KK>> FreeBSD src repository
KK>>
KK>> Modified files:
KK>> usr.bin/make cond.c cond.h for.c for.h parse.c parse.h
KK>> Log:
KK>> Rework the directive parsing code. Instead of using a lot of strcmp()s
KK>> on every line that starts with a dot use a minimal perfect hash
KK>> function and a single strcmp() on the first word after the dot
KK>> to find out whether it is really a directive call and, if yes, which
KK>> one. Then directly dispatch to a handler function for that directive
KK>> (or fall through to the dependency handling code). This makes the
KK>> directive parse a little bit more strict about the syntax: the directive
KK>> word must be followed by a character that is not alphanumerical and not
KK>> an underline (making .undefFOO illegal); .endif and .else can only be
KK>> followed by comments.
KK>
KK>I assume you've tested that this doesn't cause problems for anything
KK>in the ports collection?
I didn't test all of the ports collection - just a number of ports. But I
grepped the ports infrastructure and the ports Makefile* for problematic
constructs and found one problem that now shows up (under certain
conditions) instead of beeing hidden:
mail/dspam
mail/dspam-devel
both of them use
. elseif ...
This has been intepreted by make as a plain .else without any warning up
to now. Now it is just ignored when the .if defined (WITH_MYSQL40) ... is
false and give an error if it is true. I'll inform the maintainer about
this.
There may be of course ports that use our make to build. In any case the
change to the .else and .endif clauses just give a warning so the ports
maintainer have time to fix this. What could break is the use of
.undefFOO but I don't expect many of them.
harti
More information about the cvs-src
mailing list