[GRASS5] Gmake is not Gnu Make

[Glynn Clements]

Thierry Laronde wrote:

> > > What are the plans for the future? Keep this compatibility (I'm
> > > personnally against automake and the hell) or use more elaborate (why?)
> > > features that will not be portable?
> > 
> > 5.7 doesn't use gmake5 or Gmakefiles. It just uses GNU Makefiles.
> > 
> > For a sane build system, we realistically need to insist upon a make
> > which:
> > 
> > 1. Uses a Bourne shell for executing the commands.
> 
> POSIX susv3 specifies that the special macro SHELL shall be defined
> internally by make to point to the command line interpreter 'sh', and
> the standard points to the POSIX definition which is a Bourne shell.
> 
> So, if I'm not mistaken, a standard make shall interpret the commands
> via a Bourne compatible shell.

No, it simply means that you can force a command to be passed to a
Bourne shell with:

	$(SHELL) -c "..."

Which is what we do at present (see Makefile.in), and it's a nuisance.

I'd rather just require make to execute the commands via a Bourne
shell. IOW, I don't think that we should support make programs which
use a C shell (IRIX?).

Also, citing SuS/XPG/etc isn't really much use. A lot of systems don't
comply with them (including Linux, which is our most popular platform;
Cygwin doesn't either, and I doubt that MacOSX does).

> > 2. Provides an "include" feature.
> 
> POSIX shell is a very restricted subset of the make utilities. And there
> is no POSIX include target.
> 
> But I had the surprise to see `include' accepted by the FreeBSD make,
> when I thought that only '.include' was accepted. The reason is:
> 
> SYSVINCLUDE
>  *      Recognize system V like include directives [include "filename"]
> 
> that is a SysV compatibility defined at compile time.
> So this may or may not be present on different BSD flavors.

Without an include feature, we are stuck with the gmake5 approach,
which is to generate the actual Makefiles via some kind of
preprocessor which glues together all of the relevant fragments.
Personally, I think that's going too far.

> > 3. Provides an adequate syntax for pattern rules.
> 
> I suspect this is were there would be a lot of difference and perhaps no
> common case (and there is no POSIX standardisation).

Again, gmake5 gets around this issue by simply generating a separate
compilation rule for every .o file. However, pattern rules are an
absolute necessity for any sane build system.

> > We should make a reasonable attempt to support any make program which
> > meets the above requirements. Over-engineering the build system in
> > order to support every make program in existence (which is basically
> > the case for gmake5) isn't worth it. OTOH, we shouldn't insist upon
> > GNU make just because we don't want to bother with relatively minor
> > compatibility issues.
> 
> Well, I think that there is two alternatives (and only two, nothing in
> the middle):
> - whether go the traditionnal Grass make way, that is letting bourne
> shell script constructs portable makefiles;
> - or adopt one between multiple flavors, i.e. GNU make or P make since a
> syntax working on one may fail on the other.

Personally, I wouldn't have a problem with simply requiring GNU make
if all of the alternatives had significant issues (and requiring the
use of a preprocessor is a significant issue).

I'm just saying that, if another make program was close enough that it
only imposed minor constraints, then we should support it. Not
supporting another make program because of genuine issues is OK; not
supporting it because we can't be bothered to consider the issues
isn't.

The situation isn't the same as for the choice of a compiler, where
there is a strong imperative to use the system's "official" compiler
(i.e. avoiding portability issues by saying "you must use gcc" is
completely unacceptable). The choice of make utility only affects the
process, not the end result.

-- 
Glynn Clements <glynn.clements at virgin.net>