Updated: vim-7.3-1

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Updated: vim-7.3-1

Chris Sutcliffe-2
I've packaged vim 7.3.138 as vim 7.3-1 for MSYS.  It's available via
mingw-get:

mingw-get update
mingw-get install msys-vim

or if you already have it installed:

mingw-get update
mingw-get upgrade msys-vim

I configured vim with the following options:

./configure --prefix=/ \
--with-compiledby=[hidden email] \
--datarootdir=/share \
--docdir=/share/doc/vim/7.3 \
--sbindir=/sbin \
--libexecdir=/sbin \
--sysconfdir=/etc \
--localstatedir=/var \
--disable-gui \
--with-tlib=termcap \
--with-features=huge

vim now builds out of the box for MSYS without any modification.

Please report any issues to this mailing list.

Thank you,

Chris


------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: Updated: vim-7.3-1

Charles Wilson-8
On 3/18/2011 4:29 PM, Chris Sutcliffe wrote:

> --with-features=huge

Doesn't this mean that msys-perl is now required? Or is that just if you
want to use the (pseudo)embedded perl functionality?

BTW, it's usually been the convention that msys packages are configured
with --prefix=/usr and not /, *EVEN THOUGH* /usr is identical to / given
the enforced MSYS mount structure.  I'm not sure it makes a difference
-- but it costs nothing so I'm not really sure why it should be changed.


FYI, I'm not entirely thrilled with the -src packaging. At least with
7.3 there is no more issue with combining upstream's separate "src" and
"rt" tarballs, as upstream now packages them together.

However, you've marked this as patchlevel 138, so I can only assume the
msys-src tarball has already had those patches applied.  Hmm...shades of
the ongoing RHEL 6.0 kernel sources controversy:
        http://lwn.net/Articles/431854/
        http://lwn.net/Articles/432012/

There's no build script (or even simply build instructions, other than
your mailing list post which given gmane and sourceforge's abysmal
search facilities, will effectively by lost in the ether within a month
or two).

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.

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.

But, you know what?

I didn't have to do it.

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.


One of these days I'll finish my "msysport" tool, a bastardization of
cygwin's cygport.  simple gentoo ebuild-like scripts to create msys
packages, mmmmm....

--
Chuck

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: Updated: vim-7.3-1

Charles Wilson-8
On 3/18/2011 5:23 PM, Charles Wilson wrote:
> 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.

Which may be sooner rather than later.  Chris, in order to work nicely
with cmd.exe, the hardlinked (copies) of vim.exe should all have .exe
endings...(vimtutor is a shell script, xxd.exe is a different prog)

msys-7.2-2
-rwxr-xr-x cwilson/admin 1399808 2010-04-26 22:04 bin/ex.exe
-rwxr-xr-x cwilson/admin 1399808 2010-04-26 22:04 bin/rview.exe
-rwxr-xr-x cwilson/admin 1399808 2010-04-26 22:04 bin/rvim.exe
-rwxr-xr-x cwilson/admin 1399808 2010-04-26 22:04 bin/view.exe
-rwxr-xr-x cwilson/admin 1399808 2010-04-26 22:04 bin/vim.exe
-rwxr-xr-x cwilson/admin 1399808 2010-04-26 22:04 bin/vimdiff.exe
-rwxr-xr-x cwilson/admin    2084 2010-04-26 22:04 bin/vimtutor
-rwxr-xr-x cwilson/admin   13824 2010-04-26 22:04 bin/xxd.exe

msys-7.3-1
-rwxr-xr-x Chris/admin 1542144 2011-03-18 13:31 bin/ex
-rwxr-xr-x Chris/admin 1542144 2011-03-18 13:31 bin/rview
-rwxr-xr-x Chris/admin 1542144 2011-03-18 13:31 bin/rvim
-rwxr-xr-x Chris/admin 1542144 2011-03-18 13:31 bin/view
-rwxr-xr-x Chris/admin 1542144 2011-03-18 13:31 bin/vim.exe
-rwxr-xr-x Chris/admin 1542144 2011-03-18 13:31 bin/vimdiff
-rwxr-xr-x Chris/admin    2084 2011-03-18 13:31 bin/vimtutor
-rwxr-xr-x Chris/admin   13824 2011-03-18 13:31 bin/xxd.exe


Short term fix: you could simply unpack -bin, rename the executables,
and re-upload the new -bin archive with the same name, version, and
release number, since few people will be affected if you do it soon.

--
Chuck

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: Updated: vim-7.3-1

Chris Sutcliffe-2
In reply to this post by Charles Wilson-8
On 18/03/2011 5:23 PM, Charles Wilson wrote:
> On 3/18/2011 4:29 PM, Chris Sutcliffe wrote:
>> --with-features=huge
> Doesn't this mean that msys-perl is now required? Or is that just if you
> want to use the (pseudo)embedded perl functionality?

I don't believe so, :version reports '-perl':

Huge version without GUI.  Features included (+) or not (-):
+arabic +autocmd -balloon_eval -browse ++builtin_terms +byte_offset
+cindent -clientserver -clipboard +cmdline_compl +cmdline_hist
+cmdline_info +comments +conceal +cryptv +cscope +cursorbind
+cursorshape +dialog_con +diff +digraphs -dnd -ebcdic +emacs_tags
+eval +ex_extra +extra_search +farsi +file_in_path +find_in_path +float
+folding -footer +fork() +gettext -hangul_input +iconv
+insert_expand +jumplist +keymap +langmap +libcall +linebreak
+lispindent +listcmds +localmap -lua +menu +mksession +modify_fname
+mouse -mouseshape +mouse_dec -mouse_gpm -mouse_jsbterm +mouse_netterm
-mouse_sysmouse +mouse_xterm +multi_byte +multi_lang
-mzscheme +netbeans_intg -osfiletype +path_extra -perl +persistent_undo
+postscript +printer +profile -python -python3 +quickfix
+reltime +rightleft -ruby +scrollbind +signs +smartindent -sniff
+startuptime +statusline -sun_workshop +syntax +tag_binary
+tag_old_static -tag_any_white -tcl -terminfo +termresponse +textobjects
+title -toolbar +user_commands +vertsplit +virtualedit
+visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows
+writebackup -X11 -xfontset -xim -xsmp -xterm_clipboard
-xterm_save

> BTW, it's usually been the convention that msys packages are configured
> with --prefix=/usr and not /, *EVEN THOUGH* /usr is identical to / given
> the enforced MSYS mount structure.  I'm not sure it makes a difference
> -- but it costs nothing so I'm not really sure why it should be changed.

I tried that at first, but the DESTDIR captures '/usr' in the tarball,
so I dropped it to '/'.  I suppose I could filter out '/usr' when
creating  the tarball.

> 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.

> 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.

> 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).

> One of these days I'll finish my "msysport" tool, a bastardization of
> cygwin's cygport.  simple gentoo ebuild-like scripts to create msys
> packages, mmmmm....

I look forward to having something like this.  ;)

Cheers!

Chris


------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: Updated: vim-7.3-1

Chris Sutcliffe-2
In reply to this post by Charles Wilson-8
On 18/03/2011 5:30 PM, Charles Wilson wrote:
> Which may be sooner rather than later. Chris, in order to work nicely
> with cmd.exe, the hardlinked (copies) of vim.exe should all have .exe
> endings...(vimtutor is a shell script, xxd.exe is a different prog)

Hrmm....  I suppose.  This is an 'msys' package, so I suppose it could
be argued that it shouldn't be called directly from cmd.exe, but point made.

I'll address this and the other concerns you've raised in a new release
later tonight.

Cheers!

Chris


------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: Updated: vim-7.3-1

Charles Wilson-8
In reply to this post by Chris Sutcliffe-2
On 3/18/2011 5:51 PM, Chris Sutcliffe wrote:
> On 18/03/2011 5:23 PM, Charles Wilson wrote:
>> On 3/18/2011 4:29 PM, Chris Sutcliffe wrote:
>>> --with-features=huge
>> Doesn't this mean that msys-perl is now required? Or is that just if you
>> want to use the (pseudo)embedded perl functionality?
>
> I don't believe so, :version reports '-perl':

Right; perl support requires to be explicitly enabled, even if +huge.

>> BTW, it's usually been the convention that msys packages are configured
>> with --prefix=/usr and not /, *EVEN THOUGH* /usr is identical to / given
>> the enforced MSYS mount structure.  I'm not sure it makes a difference
>> -- but it costs nothing so I'm not really sure why it should be changed.
>
> I tried that at first, but the DESTDIR captures '/usr' in the tarball,
> so I dropped it to '/'.  I suppose I could filter out '/usr' when
> creating  the tarball.

Yep, that's the way we've been doing them:
  --prefix=/usr
  make install DESTDIR=/foo
  (cd /foo/usr && tar -cvf ...)

>> 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...
:-)

>> 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.

>> 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.
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...


The main reason for *automation* -- as opposed to documentation -- is to
*specifically* allow other maintainers to come in and easily reproduce
your work, in the event of a security fix, bus+Linus event, etc.  And,
since documentation always gets out of date, automated build scripts
force an eat-your-own-dogfood mentality.

Without such a script (or, if an earlier script already exists but one
ignores it), then anyone attempting to rescue a floundering package
basically has to start from scratch -- and previous lessons learned get
forgotten. (Case in point: the .exe thing was a bug fix at some point,
and was captured in the build script as part of the msys_install() function:

  ...
  pushd ${instdir}${PREFIX}/bin 2>/dev/null
  for f in ex rview rvim view vimdiff
  do
    if [ -e $f ]
    then
      rm -f $f
    fi
    if [ -e $f.exe ]
    then
      rm -f $f.exe
    fi
    ln vim.exe $f.exe
  done
  popd 2>/dev/null
  ...

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.

We don't normally #define __CYGWIN32__ and your ./configure recipe
didn't mention CFLAGS settings.

While cygwin's gcc defines that old macro -- and lots of vim source is
(was?) conditionalized on the __CYGWIN32__ variant.  Hence the
        vim-7.2-2-msys.patch
So unless you added both -D__CYGWIN__ -D__CYGWIN32__ to CFLAGS, or
upstream (finally) switched to all __CYGWIN__ and no __CYGWIN32__ AND
you added -D__CYGWIN__, or upstream magically added also #if
defined(__MSYS__) conditionals...I'm concerned.  Unless something fancy
is happening behind the scenes, msys-vim won't be compiled with any of
the necessary *cygwin*izations.

(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.

Anyway, did you run the vim testsuite?

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...)

It's just...why not use the script?  It's already there and just needs
tweaking for 7.N+1 most likely...

My build scripts are structured like this, BTW:

#/bin/sh
... setup and var defs ...
... function definitions ...
# and nothing /actually happens/ until the very end,
# where the functions are invoked one after another:

msys_conf_prep
msys_conf
msys_build
msys_check
msys_install
msys_package

This makes for (relatively) easy step-wise operation, by commenting out
various lines at the end of the script.  That gets tricky vs.
msys_package().  I tend to do this:


# msys_conf_prep
# msys_conf
# msys_build
# msys_check
# msys_install
sleep 30
msys_package

And then, after invoking the script for my piecewise 'package' step, I
edit the script from another window -- while the original window is
stuck in the sleep 30 -- to un-comment-out the lines and remove the
sleep.  This way the package gets a do-it-all version of the build script.

/that's/ a bit clunky, but I didn't want to add an arg-parsing loop to
the build script. At least not until I go /all out/ and finish the
msysport project...

--
Chuck

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: Updated: vim-7.3-1

Chris Sutcliffe-2
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


------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: Updated: vim-7.3-1

Keith Marshall-3
In reply to this post by Charles Wilson-8
On 19/03/11 05:49, Charles Wilson wrote:
>> 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.

However, the stock Win32 build from mercurial's own web site runs just
fine, as a native Win32 application run from an MSYS shell.  If it
weren't for a pathological reluctance to adopt tools we haven't built
for ourselves, I myself would choose mercurial over git every time.

--
Regards,
Keith.

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: Updated: vim-7.3-1

Charles Wilson-8
In reply to this post by Chris Sutcliffe-2
On 3/19/2011 9:19 AM, Chris Sutcliffe wrote:
> 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.  ;)

Thanks -- I really did not mean to imply you must, or even should, take
the time to do this right now, for 7.3.  But I'm glad you did.

>> 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.

OK.  I'm not concerned about our "pathological reluctance" regarding
external tools in this case, because anyone who wants to rebuild 7.3-N
will already HAVE the source tarball, and won't need mercurial.

And, of course, the evil RHEL bundled patch issue doesn't apply when the
DCVS repository is exposed to the world.

>> 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 ;) ).

Ack.

>> 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.

Talk about understatements...<g>

>> 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 yeah, right.  Duh.  I was the one who asked Cesar to make that happen.

>> $ 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.

Looks that way.

>> 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.

It's a bit tiresome.  And IIRC you have to attend it, there are some
points that it needs user input I think, at least on msys.

> 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". :)

<g>

> Thank you for taking the time to review the package.

It's a lot easier than rebuilding it myself, so thank YOU.  I'll take a
look at your -2 release in a day or so.

--
Chuck

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: Updated: vim-7.3-1

Charles Wilson-8
In reply to this post by Keith Marshall-3
On 3/19/2011 9:43 AM, Keith Marshall wrote:
> On 19/03/11 05:49, Charles Wilson wrote:
>> Ah...which is yet another reason why you couldn't automate this *inside
>> an msys shell*.  We don't provide mercurial.
>
> However, the stock Win32 build from mercurial's own web site runs just
> fine, as a native Win32 application run from an MSYS shell.  If it
> weren't for a pathological reluctance to adopt tools we haven't built
> for ourselves, I myself would choose mercurial over git every time.

Well, there's a difference between the current case, where somebody who
wants to update msys-vim to a version newer than that bundled inside
Chris's -src tarball would need to have mercurial to do so, and

Anybody who wants to develop/modify the software we maintain (mingw-get,
MSYS itself, etc) would need mercurial/git/etc.

In the former case, I don't see much problem "requiring" a tool we don't
provide.  In the latter case...I find that more problematic, especially
if the tool in question requires Visual anything, to be compiled on win32.

--
Chuck

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys
Reply | Threaded
Open this post in threaded view
|

Re: Updated: vim-7.3-1

Chris Sutcliffe-2
In reply to this post by Charles Wilson-8
On 19/03/2011 12:31 PM, Charles Wilson wrote:
> On 3/19/2011 9:19 AM, Chris Sutcliffe wrote:
> 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.
> It's a bit tiresome.  And IIRC you have to attend it, there are some
> points that it needs user input I think, at least on msys.

I've run it now and only test49 fails, which is expected and can be
corrected as per the instructions in the test itself.

>> Thank you for taking the time to review the package.
> It's a lot easier than rebuilding it myself, so thank YOU.  I'll take a
> look at your -2 release in a day or so.

I've released 7.3-2 now, so please let me know what you think.

Cheers!

Chris


------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Mingw-msys mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-msys