>Are you talking about bmake's specification?
>You think find first sys.mk in DEFAULT_MAKESYSPATH and read only it?
>Unfortunately today's bmake's implementation try ALL sys.mk in
>DEFAULT_MAKESYSPATH.

That is a bug.  Lst_FindFrom is expecting ReadMakefile to return 0
on success, but it returns 1.  Since there is only one case where
ReadMakefile is expected to return true on success, the fix is pretty
simple.  Alternatively, ReadMakefile could be wrapped in a
ReadFirstMakefile func that returned 0 on success.

> >2. ${MAKEFILE} issue(devel/bmake)

>> I think we need Todd's input here...
>> I don't have access to one of these systems, so have to go by the input
>> from those that do. 
>
>He tell us about it yesterday in tech-pkg:
>http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=28392

That tells me that he thinks it is unwise for pkgsrc to re-use
${MAKEFILE}, which seems somewhat orthogonal.
If btw that's a reference to using -f ${MAKEFILE} in bsd.pkg.mk,
that is exactly what the variable is for.
The only sus bit I see is
MAKEFILE?=                Makefile
which wouldn't be necessary if bmake wasn't prevented from setting it.

--sjg