|
From: Chris S. <ir0...@gm...> - 2011-03-19 13:19:34
|
On 19/03/2011 1:49 AM, Charles Wilson wrote: > On 3/18/2011 5:51 PM, Chris Sutcliffe wrote: >> On 18/03/2011 5:23 PM, Charles Wilson wrote: >>> In the FRS release area, there's no release notes. >>> There's no [/usr]/share/doc/MSYS/vim-7.3-1-msys.RELEASE_NOTES.txt >>> either, so that's probably why. >> Fair enough, I'll capture my build instructions there. > Yep...that makes it easier to keep notes like > + Remember to make sure the bin/* hardlinks to vim.exe > all have .exe extensions... > :-) I've repackaged vim 7.3 and included a build script and an MSYS specific README (based on your RELEASE_NOTES). I've even remembered to add the '.exe' extension to the hardlinked files. ;) >>> Frankly, I'm surprised that you seem to have worked *harder* -- manually >>> installing 37 different patches (1-100, +101..138) to generate the -src >>> package, and apparently manually typing commands to create the various >>> .tar.lzma's -- than simply re-using and editing the existing automated >>> structure from vim-7.2-2-src's msys-build-vim script. >> Actually I didn't work that hard at all, I simply pulled that latest >> source from Mercurial, so no manual patching was required. > Ah...which is yet another reason why you couldn't automate this *inside > an msys shell*. We don't provide mercurial. Exactly, the README provides details on how to pull vim source using Mercurial. >>> So...I suggest that for the next revision, whenever anybody feels like >>> it or gets around to it, restore some of these items like release notes >>> and automated build scripts. >> I agree with the release notes, but I'm not sure about the automated >> build scripts, since I have never supplied them before with any other >> package I've provided (I seem to remember having this discussion before >> but can't seem to find a reference to it). > Well, that's why it is a suggestion, not a command. (I'll point out > again that w32api and mingwrt are "special"... and gdb. Dang, gdb. I've seen the light and added an automated build script (it made my life easier ;) ). > Well, if EVER there was an msys package that could use some > documentation on how to get the darned thing built and working on msys, > it's gdb... Indeed, the next time I package gdb I'll add an automated build script, including make, since they both are finicky to build. > Also, oould you speak more to the "vim-7.3 builds out of the box on > msys" thing? We don't typically send MSYS patches upstream; we > typically #define __CYGWIN__ and adapt as necessary. It's not needed, something Andy and I figured out when porting mintty. This was run from an 'msysdvlpr' shell: Chris@Chris-PC ~ $ gcc -dM -E - < /dev/null | grep CYGWIN #define __CYGWIN__ 1 #define __CYGWIN32__ 1 > (Oh, and vim-7.2 relies on a particular posix-conforming behavior of > fchdir IF fchdir() exists. MSYS has fchdir() but it is broken in a > particular case, which vim doesn't like. Hence, 7.2-2 does this: > > ### avoid fchdir, force termcap > export ac_cv_func_fchdir=no > export vim_cv_terminfo=no > > prior to running configure. (Looks like the terminfo/termcap thing isn't > necessary with 7.3, but I bet the other is... > > $ objdump -p vim.exe | grep fchdir > <nothing> > > Hmm. Maybe not. I saw that you had specifics around fchdir in your patch set, but as you've also noticed, I assume vim's configure must now either not use fchdir or check to see if it's broken and work around it. > Anyway, did you run the vim testsuite? That I didn't do. I'm updating my build script to run it now and will include it in the next release. > I'm not saying you HAVE to do a build script, nor that if you do that it > must look like the one from 7.2. Or that you should bother right now, > while trying to get 7.3 done. (Maye for 7.4...) I'm going to upload a '-2' release with these changes, as my Grandfather used to say, "if a job's worth doing, it's worth doing right". :) Thank you for taking the time to review the package. Chris |