Re: some modernizations to the documentation (esp. VPATH builds)

[Ralf Wildenhues]

* Paul Eggert wrote on Mon, Jun 05, 2006 at 10:48:31AM CEST:
> Ralf Wildenhues <address@hidden> writes:
> 
> >> I recently discovered that VPATH builds don't work for Solaris make.
> >
> > Well, they do work.
> 
> I suppose it depends on the definition of "work".  It doesn't work for
> coreutils CVS "make check".  This is because the Coreutils + Automake
> trick of doing something like this:
> 
>         TESTS = foo bar baz
> 
>         TESTS_ENVIRONMENT = \
>           PROG=$$tst
> 
>         check-TESTS: $(TESTS)
>                 @failed=0; all=0; xfail=0; xpass=0; skip=0; \
>                 srcdir=$(srcdir); export srcdir; \
>                 list='$(TESTS)'; \
>                 if test -n "$$list"; then \
>                   for tst in $$list; do \
>                     if test -f ./$$tst; then dir=./; \
>                     elif test -f $$tst; then dir=; \
>                     else dir="$(srcdir)/"; fi; \
>                     if $(TESTS_ENVIRONMENT) $${dir}$$tst; then \
> 
> mishandles the assignment to PROG because foo and baz are turned into
> .../foo and .../baz, but bar is not.  I spent an hour or two trying to
> fix this portably but haven't succeeded yet.

Assuming you want the value of the basename of $$tst,
   TESTS_ENVIRONMENT = \
        PROG=`echo "$$tst" | sed 's|.*/||'`

should work reliably: since this is the right hand side of a shell
variable assignment, there is no need to fear word splitting (and no
need to cater for w32 here, as we know we use GNU make there).  If
OTOH you want PROG to contain the path in all cases, use
   TESTS_ENVIRONMENT = \
        PROG=$$dir/$$tst

Note that anyway you are using Automake internals, as `$tst' is not
documented, neither is `$dir'.

What am I missing?  (The Automake documentation implicitly requires that
$(TESTS_ENVIRONMENT) be expanded before the test, and not as command
line arguments to the test.)

> > I think advising users to use GNU make for VPATH builds is fine; I'd
> > still like to encourage developers to write portable Makefile.am's
> > though, even if it's not easy.
> 
> I suppose we could put more encouragement into the documentation, yes.
> (Is that what you mean?)

Well, yes, this is what I meant: encourage developers to write portable
Makefile.am's.  But this isn't important now.

> >   AC_C_BACKSLASH_A has only been introduced in 2.54,
> 
> That was back when GNU programs still ported to K&R.  It is
> obsolescent now, since C89 requires \a.

OK.

> >   AC_FUNC_LSTAT                                2.50,
> >   AC_FUNC_STAT                                 2.50,
> 
> As far as I know these macros are useful only for SunOS 4 and
> circa 1998 Hurd, but those systems aren't relevant any more.

Hmm, ok.

> >   AC_FUNC_LSTAT has seen changes in 2.53,
> >   AC_FUNC_SETVBUF_REVERSED          2.54.
> 
> Hmm, what changes were these?

Dunno.  Hmm, maybe those were bugfixes only.

> >     * lib/autoscan/autoscan.list: Do not suggest obsolescent macros
> >     any more.
> 
> I'd leave this patch out for now.  Some of the suggestions are still
> reasonable (e.g., if you invoke _doprint, you should call
> AC_FUNC_VPRINTF, precisely because you're trying to port to K&R).
> Others need reworking (e.g., dirent.h should suggest
> AC_CHECK_HEADERS).  In the meantime it isn't a bug to suggest
> obsolescent macros that still work.

OK.

Cheers,
Ralf