Re: Use $(MKDIR_P) instead of @MKDIR_P@

[Jim Meyering]

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 @address@hidden

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.