Re: Are the patches used to build git on cygwin available in a git repo somewhere?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 03/31/2010 08:35 PM, Jonathan Nieder wrote:
> I just fetched the packaging.
> 
>   http://mirror.mcs.anl.gov/cygwin/release/git/git-1.6.6.1-1-src.tar.bz2
> 
> gitk - work around stderr redirection on Cygwin
> 
>   The description of this patch suggests it is meant to work around
>   the old Tcl/Tk version.  In that case, maybe stock gitk should learn
>   a workaround.  I don’t think it is supposed to require more recent
>   Tcl/Tk than 8.4.
> 
>   Unfortunately, I cannot find a relevant changelog entry.  Maybe
>   this is a Windows-specific bug?  http://wiki.tcl.tk/2620
>   describes a similar problem.

More of a problem of the fact that cygwin tcl is _still_ stuck with a
bastardized implementation that is not quite a true cygwin app, and
therefore doesn't handle file redirections as gracefully as it could.
Mark Levedahl proposed the patch upstream on 14 Jun 2008, but it was
never accepted.
http://marc.info/?t=121346288300001&r=1&w=2

> 
> gitk - convert gitk-path to Windows if on Cygwin
> 
>   This patch seems reasonable, and it only affects Cygwin.  I think it
>   looks reasonable for inclusion in stock gitk, though others might
>   disagree.

OK, I'll find time to re-submit it upstream.   It was modified from this
original post, also by Mark Levedahl:
http://marc.info/?l=git&m=121349005001446&w=2

> 
> Documentation/Makefile
> 
>   Adds --unsafe to the asciidoc command line.  Why?

Because VPATH builds of the documentation make asciidoc fail otherwise,
due to a complaint about an unsafe use of ../ referencing to find the
source dir outside of the build dir.

> 
> Makefile
> 
>   Stops disabling so many features, since Cygwin has come a long way.
>   This looks worth applying upstream.  The conservative thing to do
>   would be to test $(uname -r), but since it is easy to bring a
>   Cygwin installation up to date and hard to figure out the appropriate
>   versions, it might make sense to make this change unconditionally.

Most of those defaults cater to cygwin 1.5, which was released several
years ago.  Cygwin 1.7 is the only supported version now, but it was
only released late 2009.  I'll try to find time to submit the
less-controversial of these upstream.

> 
>   A worrisome one is NO_MMAP.  Was that problem ever understood?  Maybe
>   v1.6.3-rc0~133 (MinGW: implement mmap, 2009-03-13) contains some clues
>   (just a hope).  The message for v1.5.0-rc1~182 (Set NO_MMAP for Cygwin
>   by default, 2006-12-27) indicates that it’s filesystem-specific, 

No one has ever demonstrated to me why NO_MMAP was needed on cygwin.
I'd rather get mmap fixed on cygwin, if it really is a bug (and if it
still exists; it is highly likely that the bug was against 1.5 but has
been fixed in the meantime).

> 
> Makefile: all:: perl/perl.mak
> 
>   Should be unnecessary. The scripts should pull it in already.

It made a difference for me when packaging for cygwin.  But if there's a
way to make it work without that line, I'm all ears.

> 
> Makefile: setting INSTALLDIRS=vendor in the perl/perl.mak target
> 
>   Should be unnecessary.  Make passes on variable settings from the
>   command line to submakes already.

Again, I could never get it to work without this patch; but I'm all ears
if there's a better way.

> 
> git-gui/Makefile:
> 
>   Change to Cygwin-specific part.  Probably applicable upstream.

OK, I'll try and find time to send an upstream patch submission.

Meanwhile, I'm trying to package git 1.7.0.4 for cygwin, so this is a
good chance to review all of those patches in the cygwin port.

-- 
Eric Blake   eblake@xxxxxxxxxx    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]