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