Re: LONG: Limitations of Make (Portable Shell Programming chapter of Autoconf)

[Peter Eisentraut]

Alexandre Duret-Lutz writes:

> Limitations of Make
> ===================

Random nitpicking below...

>    Make itself suffers a great number of limitations, only a few of
> which being listed here.  First of all, remember that since commands are
> executed by the shell, all its weaknesses are inherited...
>
> `$<'
>      POSIX says that the `$<' construct in makefiles can be used only
>      in inference rules and in the `.DEFAULT' rule; its meaning in
>      ordinary rules is unspecified.  Solaris 8's `make' for instance
>      will replace it with the argument.

Argument of what?

> Leading underscore in macro names

The text uses "macro" and "variable" interchangeably.  You should probalby
stick to one.

>      Some Make don't support leading underscores in macro names, such

Be consistent about capitalization (or not) of "Make".

> `make variable=value' and sub-`make's.
>      An command argument definition such as `foo=bar' overrides any foo

"A command"


>      You have a few possibilities if you do want the `foo=bar' override
>      to propagate to sub-`make's.  One is to use the `-e' option, which
>      cause all environment variables to have precedence over the

"causes"

>      `Makefile' definitions, and declare foo as an environment variable:

>      However not all Make implementations will make this exception.
>      specially.  For instance it's not surprising that OSF/Tru64 Make
       ^^^^^^^^^^
?

>      doesn't protect `SHELL', since it doesn't use it.

> `VPATH'
>      There is no `VPATH' support specified in POSIX.  Many Makes have a
>      form of `VPATH' support, but its implementation is not coherent
>      amongst Makes.

"consistent", not "coherent"

>      Maybe the best suggestion to do to people who needs the `VPATH'

"give" ... "need"

>      feature is to chose a Make implementation an stick to it.  Since

"choose" ... "and"

>      the resulting `Makefile's are not portable anyway, better chose a
>      portable Make (hint, hint).
>
>      Here are a couple of known issues with some `VPATH'
>      implementations.
>
>     `VPATH' and double-colon rules
>           Any assignment to `VPATH' causes Sun Make to only execute the
>           first set of double-colon rules.  (This comments is here

"This comment has been here"

>           since 1994 and the context has been lost.  It's probably
>           about SunOS 4.  If you can reproduce this, please send us a
>           testcase for illustration.)
>
>     `$<' in inference rules:
>           An implementation a make would not adjust prefix `$<' this
>           prerequisite have been found in a `VPATH' dir.  This means
>           that

confusing grammar

>           This can be fixed as follow.

"follows"

>           This kludge was introduced in Automake in 2000, but the exact
>           context have been lost.  If you know which make

"has"

>           implementation is involved here, please drop us a note.
>
>     `$<' not supported in explicit rules
>           As said elsewhere, using `$<' in explicit rules is not
>           portable.  You have to make a `VPATH' search manually.  For

"You have to do (perform)"

>           instance, using the same pattern as above:

>           However, for the sake of other Make implementations, we can't
>           rely on this, and we have to search `VPATH' manually:
>
>                VPATH = ../src
>                foo.o: foo.c
>                        cc -c `test -f foo.c || echo ../src/`foo.c -o foo.o
>
>           however the "prerequisite rewriting" still applies here.  So

"However" (capitalized)

>           if `foo.c' is in `../src', SunOS Make will execute
>
>                `cc -c `test -f ../src/foo.c || echo ../src/`foo.c -o foo.o'
>
>           which reduces to
>
>                cc -c foo.c -o foo.o
>
>           and thus fails.  Oops.
>
>           One workaround is to make sure that foo.c never appear as a

"appears"

>           plain word in the rule.  For instance these three rules would
>           be safe.
>
>                VPATH = ../src
>                foo.o: foo.c
>                        cc -c `test -f ./foo.c || echo ../src/`foo.c -o foo.o
>                foo2.o: foo2.c
>                        cc -c `test -f 'foo2.c' || echo ../src/`foo2.c -o 
> foo2.o
>                foo3.o: foo3.c
>                        cc -c `test -f "foo3.c" || echo ../src/`foo3.c -o 
> foo3.o

>           Deciding to quote `$(HEADERS)' in some way, like we did for
>           `foo.c' a few `Makefile's ago, do not help:

"does"

-- 
Peter Eisentraut   address@hidden