* Stefano Lattarini wrote on Wed, Sep 15, 2010 at 01:26:50PM CEST: > OK for maint?
I really think you should use an extra function normalize_file_name to do the job, for maintainability. Please run make maintainer-check. Typo patologic. A couple more nits below. I don't think we want subobj11c.test. What we want instead, and I agree with your earlier sentiments on this, is unit testing for the normalize_file_name function. Which suggests that it should be in lib/Automake/FileUtils.pm I guess, and the test below lib/Automake/tests. ;-) If you need help, I can give more hints. In case you're fed up, I can also do the rest, eventually. Thanks, Ralf > Work around a bug in file-inclusion mechanism of Solaris make. > > * automake.in (handle_single_transform): In the name of the > dependency file: collapse multiple slash characters into a single > one. > * tests/subobj11a.test: New test. > * tests/subobj11b.test: Likewise. > * tests/subobj11c.test: Likewise. > * tests/Makefile.am (TESTS): Updated. > * NEWS: Updated. > + # The following substitution is required to work around a bug > + # of Solaris make (still present in Solaris 10). > + # If we have a Makefile containing a file inclusion like this: > + # include .//foo.mk > + # Solaris make fails with a message like: > + # make: ... can't find `/foo.mk': No such file or directory > + # make: fatal error ... read of include file `/foo.mk' failed > + # (even if the file `foo.mk' exists). > + # The error disappear by collapsing the repeated slash `/' disappears > + # characters into a single one. However, we must be careful > + # in doing so, since Posix lets implementations treat leading > + # // specially (see "File System Conventions" in the Autoconf Can we compactify this comment? Like, # $FILE_NAME # normalize_file_name ($FILE_NAME) # Flatten multiple adjacent slashes in $FILE_NAME and return it. # Solaris 10 make fails over them in an include statement. code ... # Leading slashes may be special, as per Posix.
