Date: Fri, 13 Jan 1995 15:03:16 +0900
From: Stephen Turnbull <turnbull AT shako DOT sk DOT tsukuba DOT ac DOT jp>
To: UCKO AT VAX1 DOT ROCKHURST DOT EDU
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Changing system() [was: bug in djgpp's make]

   >		 "make --list-actions | sort | uniq"
   >
   >Oh, are those non-standard utilities?  Sorry....  Which is

   You seem to have stumbled across my point here...if make could be asked
   to produce a list of programs it invokes, the makefile author could
   double-check that list to make sure it didn't involve something people
   weren't likely to have.

Make *can* be induced to produce the list of actions.  This is done by
"make -n", "make --dry-run", "make --recon", or "make --just-print"
(these are synonymous options).  The only problem is that this
wouldn't necessarily catch things done by non-default targets (such as
install: and man:, which often invoke programs like 'install' and
'nroff').

If you don't like that, you can whomp up a perl, grep, or awk script
which will find commands issued (ie, anything beginning with a TAB).
This won't catch stuff in comments that might get uncommented someday.

But the real problem with nonportable makefiles is that most authors
won't bother to check portability, and if it's a DJGPP-specific
switch, they are unlikely to even find out about the switch.

GNU Make itself isn't all that portable, at least Tony Helm doesn't
thinks so.  In his EZ-GNU package for the students at TU-Wien, he
doesn't include GNU make, he uses NDMake.  Then what?

What needs to be done is to assemble "packages" of tools, and
documents explaining how to do these things.  The documents are the
real sticking point.

    --Steve