[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Building sharutils 4.13.4 with MinGW
From: |
Bruce Korb |
Subject: |
Re: Building sharutils 4.13.4 with MinGW |
Date: |
Thu, 11 Apr 2013 09:01:31 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 |
On 04/09/13 09:21, Eli Zaretskii wrote:
Anyway, I hate it when programs lose features as result of porting
them. So the changes below resurrect the full strength of 'shar' even
when 'fork' is not available. The trick is to use shell pipes
instead.
With these changes, all the tests in v4.13.4 pass, with a single
exception: shar-1, and that failure is not a real one:
I've hacked tests/shar-1:
# adjust for variations in the package string and for
# variations in Windows capabilities.
#
sed -e "s/__PACKAGE_STRING__/${PACKAGE_STRING}/" \
-e 's/-rw-rw-rw- shar-1.in/-rw-r--r-- shar-1.in/' \
-e "s/chmod 0666 'shar-1.in'/chmod 0644 'shar-1.in'/" \
$top_srcdir/tests/shar-1.ok > ${tmpfile}.sample
Here are the changes:
I don't have time to digest this part of the patch,
other than to suggest:
#if HAVE_WORKING_FORK
#elif defined(__MINGW32__)
#else
#endif
I also haven't investigated, but I worry about adding the uuencode
command when HAVE_WORKING_FORK is zero. It changes the
printf arguments and I think the uuencode gets added on
anyhow, so wouldn't it be redundant? Dunno. Haven't looked yet.
Anyway, forcing the pipe when fork doesn't work cancels out the
--no-piping option, so this definitely needs some massaging.
--- src/shar.c~3 2013-04-09 13:37:23.287005000 +0300
+++ src/shar.c 2013-04-09 13:45:18.562796500 +0300
@@ -173,7 +173,20 @@ typedef struct {
- Re: Building sharutils 4.13.4 with MinGW, Eli Zaretskii, 2013/04/07
- Re: Building sharutils 4.13.4 with MinGW, Eli Zaretskii, 2013/04/08
- Re: Building sharutils 4.13.4 with MinGW, Bruce Korb, 2013/04/08
- Re: Building sharutils 4.13.4 with MinGW, Eli Zaretskii, 2013/04/08
- Re: Building sharutils 4.13.4 with MinGW, Bruce Korb, 2013/04/11