* [PATCH] fix removal of {cpu,machine} links on mingw/msys
@ 2013-12-28 9:58 Andrey Borzenkov
2014-01-18 18:14 ` Vladimir 'φ-coder/phcoder' Serbinenko
0 siblings, 1 reply; 4+ messages in thread
From: Andrey Borzenkov @ 2013-12-28 9:58 UTC (permalink / raw)
To: grub-devel
At least on Windows 2003 using "ln -s dir1 dir2" in msys shell succeeds,
but results in what looks like hard link. Subsequent "rm -f dir2" (e.g.
during second config.status invocation) fails. Check that we also can
remove link to directory.
Make it more clear in message that we are checking "ln -s".
---
acinclude.m4 | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/acinclude.m4 b/acinclude.m4
index 32d5477..b2bb88d 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -418,15 +418,15 @@ else
[fi]
])
-dnl Check if ln can handle directories properly (mingw).
+dnl Check if ln -s can handle directories properly (mingw).
AC_DEFUN([grub_CHECK_LINK_DIR],[
-AC_MSG_CHECKING([whether ln can handle directories properly])
+AC_MSG_CHECKING([whether ln -s can handle directories properly])
[mkdir testdir 2>/dev/null
case $srcdir in
[\\/$]* | ?:[\\/]* ) reldir=$srcdir/include/grub/util ;;
*) reldir=../$srcdir/include/grub/util ;;
esac
-if ln -s $reldir testdir/util 2>/dev/null ; then]
+if ln -s $reldir testdir/util 2>/dev/null && rm -f testdir/util 2>/dev/null ; then]
AC_MSG_RESULT([yes])
[link_dir=yes
else
--
tg: (989af02..) u/mingw/dir-links (depends on: master)
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH] fix removal of {cpu,machine} links on mingw/msys
2013-12-28 9:58 [PATCH] fix removal of {cpu,machine} links on mingw/msys Andrey Borzenkov
@ 2014-01-18 18:14 ` Vladimir 'φ-coder/phcoder' Serbinenko
2014-01-18 18:32 ` Andrey Borzenkov
0 siblings, 1 reply; 4+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2014-01-18 18:14 UTC (permalink / raw)
To: The development of GNU GRUB
[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]
On 28.12.2013 10:58, Andrey Borzenkov wrote:
> At least on Windows 2003 using "ln -s dir1 dir2" in msys shell succeeds,
> but results in what looks like hard link. Subsequent "rm -f dir2" (e.g.
> during second config.status invocation) fails. Check that we also can
> remove link to directory.
>
> Make it more clear in message that we are checking "ln -s".
>
Is there a way to reliably remove result of such test? We don't want to
leave a weird file after the test behind. Perhaps rm -rf since we know
that we test with newly-created directory?
> ---
> acinclude.m4 | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/acinclude.m4 b/acinclude.m4
> index 32d5477..b2bb88d 100644
> --- a/acinclude.m4
> +++ b/acinclude.m4
> @@ -418,15 +418,15 @@ else
> [fi]
> ])
>
> -dnl Check if ln can handle directories properly (mingw).
> +dnl Check if ln -s can handle directories properly (mingw).
> AC_DEFUN([grub_CHECK_LINK_DIR],[
> -AC_MSG_CHECKING([whether ln can handle directories properly])
> +AC_MSG_CHECKING([whether ln -s can handle directories properly])
> [mkdir testdir 2>/dev/null
> case $srcdir in
> [\\/$]* | ?:[\\/]* ) reldir=$srcdir/include/grub/util ;;
> *) reldir=../$srcdir/include/grub/util ;;
> esac
> -if ln -s $reldir testdir/util 2>/dev/null ; then]
> +if ln -s $reldir testdir/util 2>/dev/null && rm -f testdir/util 2>/dev/null ; then]
> AC_MSG_RESULT([yes])
> [link_dir=yes
> else
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 274 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-01-18 18:39 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-12-28 9:58 [PATCH] fix removal of {cpu,machine} links on mingw/msys Andrey Borzenkov
2014-01-18 18:14 ` Vladimir 'φ-coder/phcoder' Serbinenko
2014-01-18 18:32 ` Andrey Borzenkov
2014-01-18 18:39 ` Vladimir 'φ-coder/phcoder' Serbinenko
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).