On Wed, 12 Apr 2006 09:15:04, Simon Gerraty wrote:
> >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.

Hmm, if it is a bug, how about this?

   953                  ln = Lst_Find(sysMkPath, (ClientData)NULL, ReadMakefile);
   954                  if (ln != NILLNODE)
   955                          Fatal("%s: cannot open %s.", progname,
   956                              (char *)Lst_Datum(ln));

This code check & print "can't open sys.mk path name".
If change you say, "ln == first opened sys.mk full path name".

> > >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 using NFS on Interix, sometime change ${MAKEFILE} from "Makefile"
to "makefile" even if using "Makefile".

> 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.

Or simply, useing "-f Makefile".

--
"Of course I love NetBSD":-)
OBATA Akio / obata@lins.jp