[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LONG: Limitations of Make (Portable Shell Programming chapter of Aut
Re: LONG: Limitations of Make (Portable Shell Programming chapter of Autoconf)
Sun, 24 Mar 2002 21:51:15 -0500 (EST)
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
> 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
> `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.
> 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'
> `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
> This can be fixed as follow.
> This kludge was introduced in Automake in 2000, but the exact
> context have been lost. If you know which make
> 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
> 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
> 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
> foo3.o: foo3.c
> cc -c `test -f "foo3.c" || echo ../src/`foo3.c -o
> Deciding to quote `$(HEADERS)' in some way, like we did for
> `foo.c' a few `Makefile's ago, do not help:
Peter Eisentraut address@hidden