bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Solaris make and VPATH (was: parallel build of gettext may fail)


From: Ralf Wildenhues
Subject: Solaris make and VPATH (was: parallel build of gettext may fail)
Date: Mon, 30 Oct 2006 15:08:48 +0100
User-agent: Mutt/1.5.13 (2006-10-09)

Hello Bruno,

* Bruno Haible wrote on Mon, Oct 30, 2006 at 01:47:59PM CET:
> > 2) Solaris make with its dreaded VPATH rewriting "feature" will, in this
> > loop:

> Solaris 'make' is not supported for VPATH builds. See the INSTALL file:
> 
>      To do this, you must use a version of `make' that
>      supports the `VPATH' variable, such as GNU `make'.

Solaris make supports VPATH, but only in weird ways.  Let's not have
this discussion again, please; I understand if you don't want to support
it, I'm merely trying to point out that you _can_ do it.  And Automake
has basically the machinery in place to support it, it's just often not
easy to see all the pitfalls.

> Btw, can you reproduce this rewriting of variables in Solaris 'make'?

mkdir src build
touch src/a src/b src/c
cd build
tr X '\t' >Makefile <<\EOF
VPATH = ../src
F = a b c
d: $(F)
address@hidden "The first and last are not VPATH-rewritten, because"
address@hidden "after make expands $$(F), the \"make words\" are not completely"
address@hidden "surrounded by white space: '$(F)'"
address@hidden "compare with: $(F), or $(F) or :$(F) ..."
EOF
/usr/ccs/bin/make

leads to:
| The first and last are not VPATH-rewritten, because
| after make expands $(F), the "make words" are not completely
| surrounded by white space: 'a ../src/b c'
| compare with: ../src/a ../src/b c, or ../src/a ../src/b ../src/c or :a 
../src/b ../src/c ...

> saw it once around 2001 or earlier, but when I wanted to reproduce the 
> problem,
> in order to have an argument for asking the automake people to drop support
> for Solaris 'make', I couldn't.


> > Automake itself works around this (in non-inference rules) like this:
> >    ... -c `test -f '$(SOURCE)' || echo '$(srcdir)/'`$(SOURCE)
> 
> I thought this idiom was in order to cope with files that are sometimes in
> the build dir, sometimes in the source dir (such as the elements of
> $(BUILT_SOURCES).)

It is.  The two problems overlap.

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]