Re: DJGPP & destdir.test failure (Was: Re: on using`makeinfo--no-split' to solve filename conflicts)

[Richard Dawe]

Hello.

Alexandre Duret-Lutz wrote:
> 
> >>> "Richard" == Richard Dawe <address@hidden> writes:
> 
> [...]
> 
>  Richard> * destdir.test: This fails and I don't know why. I've
>  Richard> looked at it for a while. I've attached a log file
>  Richard> from the test run. Maybe you can see something I
>  Richard> can't. Let me know if there's anything I can do, to
>  Richard> help debug the destdir.test failure. I wonder if it
>  Richard> fails on other platforms too.
> 
> It works fine here.  In this test we expect `make distcheck' to
> fail because of the following commands.
> 
> [...]
> 
> dc_install_base=`CDPATH="${ZSH_VERSION+.};" && cd destdir-1.0/_inst && pwd | 
> sed -e 's,^[^:\\/]:[\\/],/,'` \
> 
> [...]
> 
>   && chmod -R a-w "$dc_install_base" \
> 
> [...]
> 
> c:/djgpp/bin/make.exe  install-data-hook
> make.exe[3]: Entering directory 
> `c:/develop/ports/gnu.dev/automake-1.7.2c/tests/testSubDir/destdir-1.0/_build'
> cp 
> c:/temp/am-dc-15416//develop/ports/gnu.dev/automake-1.7.2c/tests/testSubDir/destdir-1.0/_inst/share/foo
>  
> /develop/ports/gnu.dev/automake-1.7.2c/tests/testSubDir/destdir-1.0/_inst/share/bar
> 
> This `cp' copies a file to a read-only directory.  That isn't
> expected to work.  Apparently it does on DJGPP, as make continues.
> 
> Is there anything peculiar with read-only directories, or
> copying rights in DJGPP?

It seems that directories can always be written to, even when they are
read-only. I can write to a read-only directory using only normal DOS
commands, so this is not specific to DJGPP programs on DOS.

The install-data-hook could check for the existence of the file and fail if it
does exist. This works, but defeats the point of the test. Below is a patch
for destdir.test. I'm not very happy with it, but I can't think of a better
solution. I'm not sure it should be applied. I would not break the test, just
because of one platform.

I would not hold up a 1.7.3 release because of this problem.

Thanks, bye, Rich =]

-- 
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]

--- orig/automake-1.7.2c/ChangeLog      2003-02-19 19:26:34.000000000 +0000
+++ gnu.dev/automake-1.7.2c/ChangeLog   2003-02-20 10:57:38.000000000 +0000
@@ -1,3 +1,9 @@
+2003-02-20  Richard Dawe  <address@hidden>
+
+       * tests/destdir.test (install-data-hook): Directories are always
+       writeable on DOS, so we can't rely on the copy to fail.
+       Fail if the file was copied successfully.
+
 2003-02-19  Richard Dawe  <address@hidden>
 
        * lib/am/distdir.am (distcheck): Strip any leading DOS drive
--- orig/automake-1.7.2c/tests/destdir.test     2002-09-08 13:07:54.000000000
+0000
+++ gnu.dev/automake-1.7.2c/tests/destdir.test  2003-02-20 10:59:38.000000000
+0000
@@ -38,8 +38,14 @@ dist_data_DATA = foo
 
 # This rule is bogus because it doesn't use $(DESTDIR) on the
 # second argument of cp.  distcheck is expected to catch this.
+#
+# However, directories are always writeable on DOS, so we need
+# to check that the file was not copied. This defeats the point
+# of the test on DOS platforms, though, since the failure
+# will not be due to distcheck catching the problem.
 install-data-hook:
        cp $(DESTDIR)$(datadir)/foo $(datadir)/bar
+       test -f $(datadir)/bar && rm -f $(datadir)/bar && exit 1
 
 uninstall-local:
        rm -f $(DESTDIR)$(datadir)/bar