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
