Bruno Haible wrote:
> Jim Meyering wrote:
>> I've been lobbying to remove the obsolescent @VAR@ notation
>> in favor of $(VAR) notation for a long time.
> Using @VAR@ instead of $(VAR) removes one level of complexity, thus
> making debugging easier: If someone reports that in a Makefile,
> @FOO@ does not expand to a correct value, the next question I ask
> him: "look what's the value of FOO in config.status". Whereas when
> $(FOO) does not expand to a correct value, I have to ask 3 questions:
> - Verify that no other assignment to FOO exists in the Makefile,
> - Verify that no FOO variable assignment was passed from the parent
> directory.
> - Look what's the value of FOO in config.status.
Sometimes, there are uses like this:
MKDIR_P = @MKDIR_P@
If evidence suggests that makefile variable $(FOO) has a surprising
value, you may want to ask those first two questions, too.
Just because a particular value is substituted for @FOO@ does not
guarantee that it is the one that is ultimately used.
> Additionally, using $(VAR) implies 'make' processing: If the expansion
> contains a '#', the expansion will be truncated at that point in $(VAR)
> but not in @v...@.
I don't think we need to worry about '#' in a MKDIR_P definition.
Let's not confuse @MKDIR_P@ (with which I'd expect few such problems)
with the @SYMBOLS@ expanded in files like stdlib.in.h.
One difference may be that developers seem relatively used to tracing
through Makefile*, but those new to autoconf do not always know to
look in config.status.
> $(VAR) certainly adds a level of flexibility over @VAR@, but I find that
> rarely useful.
Why limit flexibility?
Your approach hard-codes configure-time settings into each
variable like MKDIR_P.
Consider consistency with automake-generated rules.
For example, I see these uses of $(MKDIR_P) in coreutils/lib/Makefile:
unistr/$(am__dirstamp):
@$(MKDIR_P) unistr
@: > unistr/$(am__dirstamp)
unistr/$(DEPDIR)/$(am__dirstamp):
@$(MKDIR_P) unistr/$(DEPDIR)
@: > unistr/$(DEPDIR)/$(am__dirstamp)
uniwidth/$(am__dirstamp):
@$(MKDIR_P) uniwidth
@: > uniwidth/$(am__dirstamp)
uniwidth/$(DEPDIR)/$(am__dirstamp):
@$(MKDIR_P) uniwidth/$(DEPDIR)
@: > uniwidth/$(DEPDIR)/$(am__dirstamp)
yet the ones that had @MKDIR_P@ have already been expanded
to absolute file names + options, like "/usr/bin/mkdir -p"
$(AM_V_at)/usr/bin/mkdir -p arpa
$(AM_V_at)/usr/bin/mkdir -p netinet
$(AM_V_at)/usr/bin/mkdir -p sys
$(AM_V_at)/usr/bin/mkdir -p sys
$(AM_V_at)/usr/bin/mkdir -p sys
$(AM_V_at)/usr/bin/mkdir -p sys
contrast with two from gnulib modules I maintain:
selinux/selinux.h: se-selinux.in.h
$(AM_V_at)$(MKDIR_P) selinux
...
selinux/context.h: se-context.in.h
$(AM_V_at)$(MKDIR_P) selinux
...
and commands from the automake-emitted distdir rule:
distdir: $(DISTFILES)
...
*/*) $(MKDIR_P) `echo "$$dist_files" | \
...
|| $(MKDIR_P) "$(distdir)/$$subdir" \
I think anyone wanting to use some other MKDIR_P value
would be surprised (and report it as a bug) to have to
resort to rerunning configure or config.status in order
to make the replacement consistently.
