In addition to mkdep, I've discovered a few other programs that
might cause problems depending on what platform one is cross-compiling
a NetBSD system from. As I see it, for each of these we have two
options.  

The first is to define ${PROGNAME} and ${PROGFLAGS} variables for
it in sys.mk. This allows us to include it in the cross-compilation
toolset, which is entirely separate from the toolset used to compile
programs destined for the current machine.  This is obviously
necessary for programs like cc and as.

The other option is not to do this because we are reasonably
convinced that whatever happens to be lying around on the host
system, regardless of even the operating system it's running, will
do. (I don't really see any reason to limit cross-compilation to
systems running NetBSD.) Echo and rm, for example, are not likely
to change much from system to system as long as we're running Unix.

I've collected up a list of all the programs that seem to be used
in /usr/share/mk/*.mk in -current, but don't have ${PROG} and
${PROGFLAGS} variables assigned to them.

Mkdep I covered in a previous message to this list.

Tsort has added a -q option since 1.0. I'm inclined toward adding
${TSORT} and ${TSORTFLAGS} and putting it in the cross-compililation
toolset, since it changes even between 1.0 and -current.

Ranlib from 1.0 still seems to work. How platform-dependent is this?

Gencat doesn't have a manual page, but seems to be used to generate
NLS stuff. Someone else mentioned on one of the lists recently that
the NLS files have byte-order dependencies in them. Should this go
into the tooolkit?

Does install change enough between systems to warrant putting it
into the toolset?

The other programs used, chmod, chown, echo, ln, lpr, mkdir, mv,
rm, spell and true, I don't think will be a problem.

cjs

Curt Sampson    curt@portal.ca		Info at http://www.portal.ca/
Internet Portal Services, Inc.	
Vancouver, BC   (604) 257-9400		De gustibus, aut bene aut nihil.