Re: [Mingw-msys] Updated: vim-7.3-1

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