AM_PROG_MKDIR_P overcautious?

[Stepan Kasal]

Hello,
  AM_PROG_MKDIR_P used to define mkdir_p='mkdir -p -- .'
But now it sets  mkdir_p='mkdir -p --'

m4/mkdirp.m4 contains two reasons; and IMHO none of them is valid:

  #  1. if the package is installed by a user who cannot write `.'
  #     make install will fail,

This is based on a bug report from Harlan Stenn, archived at
http://lists.gnu.org/archive/html/bug-automake/2004-07/msg00052.html

That bug reports says that `mkdir .' might fail in a read-only directory.
Well, `mkdir .' always fails, ``directory exists.''

So we all suppose that the author of the bug report meant that
`mkdir -p .' fails in a read-only directory.
But this is not true either; try
        (cd / && mkdir -p .)

I guess that a correct implementation of mkdir -p should do nothing if
the directory already exists, so there should be no problem if that
directory is not writable.

The bug report doesn't specify version of Automake; perhaps it was
Automake <= 1.8.2, which could use vendor mkdir.
(Automake >= 1.8.3 doesn't use non-GNU mkdir.)

  #  2. the above comment should most certainly read
  #     $(mkdir_p) $(DESTDIR)$(somedir)
  #     so it does not work when $(somedir) is undefined and
  #     $(DESTDIR) is not.

So it would be
        mkdir -p -- . $(DESTDIR)

Again, correct implementation of mkdir -p should do nothing.
(We may suppose that $(DESTDIR) exists, right?)

Have I missed something?

If not, I'd suggest that we remove the change from
http://lists.gnu.org/archive/html/bug-automake/2004-07/msg00061.html
and wait for another bug report.  ;-)

Have a nice day,
        Stepan Kasal