automake-patches
[Top][All Lists]
Advanced

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

Re: [PATCH] Test `$(var:suf=rpl)' expansion in special automake variable


From: Stefano Lattarini
Subject: Re: [PATCH] Test `$(var:suf=rpl)' expansion in special automake variables.
Date: Sat, 18 Dec 2010 10:35:43 +0100
User-agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )

On Saturday 18 December 2010, Ralf Wildenhues wrote:
> Hello Stefano,
> 
> * Stefano Lattarini wrote on Thu, Dec 09, 2010 at 01:46:48PM CET:
> > Test `$(var:suf=rpl)' expansion in special automake variables.
> > 
> > * tests/posixsubst-data.test: New test.
> [...]
> > * tests/posixsubst-scripts.test: Likewise.
> 
> > --- /dev/null
> > +++ b/tests/posixsubst-scripts.test
> > @@ -0,0 +1,89 @@
> 
> > +# Test that POSIX variable expansion `$(var:str=rpl)' works when used
> > +# with the SCRIPTS primary.
> 
> > +cat >> configure.in << 'END'
> > +AC_OUTPUT
> > +END
> > +
> > +cat > Makefile.am << 'END'
> > +t1 = foo1 foo2
> > +t2 = bar1x bar2
> > +t3 = quu-baz
> > +
> > +bar1 bar2 quux.pl:
> > +   : > $@
> > +CLEANFILES = bar1 bar2 quux.pl
> > +
> > +# Try also with `:=', to ensure the parser is not unduly confused
> > +# into thinking that it's an unportable assignement operator.
> 
> This comment is bogus, right?  There is no such thing as ':=' within
> $(var:A=B),
but there is in $(var:=x) (below this is "$(t1:=.sh)").

> and the code below does not use := to assign variables.
>
Indeed, and so we want to enssure the automake parser does not 
(errenously) think we are trying to do so.

> What do you mean with this text?  "Also try an empty match suffix."?
>
Yes; maybe a comment like this would be better?
  
 # Also try an empty match suffix, to ensure that the `:=' in there is
 # not confused by the parser with an unportable assignement operator.

> (Repetitious as it is, it the same text is in all the other tests of
> this patch as well.)
 
> > +installcheck-local:
> > +   ls -l $(prefix)/libexec $(prefix)/bin $(prefix)/sbin
> > +   test -f $(prefix)/sbin/foo1.sh
> > +   test -x $(prefix)/sbin/foo1.sh
> > +   test -f $(prefix)/sbin/foo2.sh
> > +   test -x $(prefix)/sbin/foo2.sh
> > +   test -f $(prefix)/libexec/bar1
> > +   test -x $(prefix)/libexec/bar1
> > +   test -f $(prefix)/libexec/bar2
> > +   test -x $(prefix)/libexec/bar2
> > +   test -f $(prefix)/bin/quux.pl
> > +   test -x $(prefix)/bin/quux.pl
> 
> These 'test -x' commands fail on MinGW/MSYS because the file system does
> not actually have execute permission information.
>
Ouch.

> Instead, it is emulated by looking at the file, and returning 0 if the
> file starts with, e.g., a COFF header or with '#!'.
> (The same heuristic is used when executing a script as well.)
> 
> You can thus fix this by either creating actual scripts in above rules
> and the file creation below, or by removing the tests here.  I'm not
> sure which you prefer.
>
I'd prefer the former, to keep the coverage a little bigger on non-MinGW
systems.  Is that ok?

Regards,
   Stefano



reply via email to

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