About Section 7.2.2 "Utilities in Makefiles" of the GCS

[Vincent Lefevre]

Hi,

I have a few comments about Section 7.2.2 "Utilities in Makefiles" of
the GNU Coding Standards.


* It is written: "Write the Makefile commands (and any shell scripts,
such as configure) to run in sh, not in csh. Don't use any special
features of ksh or bash."

But there are two incompatible sh (the traditional Bourne shell, as
used by default under Solaris, and POSIX sh), and there are some
significant differences in practice. This paragraph is not clear if
the traditional Bourne shell needs to be supported. If both need to
be taken into account, the following should be added, IMHO: "[to run
in sh] (both traditional Bourne shell and POSIX shell)".


* The list of utilities includes "diff". But unfortunately, "diff" is
not present on the Maemo/OS2008 GNU/Linux distribution (e.g. on the
Nokia N810), probably to save some space. Very often, one just needs
to know whether two files are identical or different, in which case
"cmp" could be used. But it has been reported that "cmp" has problems
on some platforms, so that "cmp" is no longer used by autoconf. Could
something be said about that? Is one of them preferred, to detect
whether two files are identical or different? Could it be advised
to test the presence of "diff", and use "cmp" if "diff" couldn't be
found?


* "Stick to the generally supported options for these programs."
is vague and misleading. People might think that POSIX options are
OK despite the given example ("mkdir -p", where -p is specified by
POSIX). I even saw developers using non-POSIX options! Could this
paragraph be more specific?

Also, concerning the "test" utility, the following should probably
be added:

  With the "test" utility, avoid ambiguity. Even though the behavior
  is specified by POSIX, many implementations behave differently.
  For instance, to test whether the length of a string is zero or
  not, use an explicit "-z" or "-n".


* "It is a good idea to avoid creating symbolic links in makefiles,
since a few systems don't support them."

It should be better to mention that some *file systems* don't support
them (now that vfat-formatted Flash memory is more and more used, e.g.
on USB keys and memory cards).

-- 
Vincent Lefèvre <address@hidden> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)