bug-automake
[Top][All Lists]
Advanced

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

bug#7833: automake uses two different values for DejaGNU srcdir


From: Ralf Wildenhues
Subject: bug#7833: automake uses two different values for DejaGNU srcdir
Date: Thu, 13 Jan 2011 08:15:19 +0100
User-agent: Mutt/1.5.20 (2010-08-04)

Hello Ian,

thanks for the bug report.

* Ian Lance Taylor wrote on Wed, Jan 12, 2011 at 10:52:09PM CET:
> When automake is configured to use DejaGNU, it uses two different values
> for srcdir.  There are two different cases in lib/am/dejagnu.am:

> check-DEJAGNU: site.exp
> ## Life is easiest with an absolute srcdir, so do that.
>       srcdir=`$(am__cd) $(srcdir) && pwd`; export srcdir; \

> site.exp: Makefile
[...]
>       @echo 'set srcdir $(srcdir)' >>site.tmp
> 
> This value is read by DejaGNU after option processing is complete,
> effectively overwriting the value passed with the --srcdir option.
> 
> The value of srcdir stored in site.exp should be an absolute path, just
> like the value passed to runtest via --srcdir.

I see that passing different values is probably not a good idea.
Passing absolute values will probably break builds in a directory
tree where some higher-up name component contains spaces, not uncommon
on w32 systems.  ATM Automake should produce makefiles that work in such
environments, as long as $(srcdir) is relative and does not contain
spaces.  IIUC then using an absolute directory name would break this.
Can we avoid it with suitable quoting?

Also, this would break moving both source and build trees (in a way that
would let relative $(srcdir) remain valid).  I'm not quite sure how good
we are elsewhere on this front, and it is not such an important feature,
but any chance we can retain it?

Am I correct in assuming that it is hopeless to assume GCC will work
when either values are relative?

Cheers,
Ralf





reply via email to

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