Updating runtime files without version control
Bram Moolenaar
Since Vim is very stable, it does not happen often that a new version is
released. Mostly it's fine to run an older version. Unless you run into
a bug there is no pressing reason to update. With the result that many
users keep using the last official release, since that's just easier.
What does change between releases is the set of runtime files. These
are updated more frequently, and often this is a more important reason
to update than getting all the patches. We often see people complaining
about a syntax highlighting error that was already fixed.
There are various ways in which users can get an updated version,
including package managers or getting the latest with git and building
yourself. For at least some people using git to get the latest version
is fine, but there is a large group of users, especially on MS-Windows
and Mac, for who this is not so easy. For this group of users I'm
thinking of the following solution.
Include a plugin with Vim that provides the command:
:RuntimeUpdate
This will get the latest files from github and put them under
$VIMRUNTIME. The user can run this once in a while, e.g. when someone
mentions it will solve the problem he experiences.
How would this work?
- Include a file $VIMRUNTIME/CONTENTS that lists all the files, with a
checksum or "DELETED".
- The plugin computes the checksum for the local file, and if it differs
from the entry in CONTENTS it fetches the new file. Github supports
direct raw access, e.g.:
https://raw.githubusercontent.com/vim/vim/master/runtime/syntax/vim.vim
- If the file was deleted, delete it (duh).
- If the $VIMRNTIME directory is not writable by the current user, put
the updates in a temp directory and generate a shell script to move
them into place. The have one "sudo" command to do the work.
- Rely on the netrw plugin to download the files.
Some things that might cause problems:
- If the line endings are changed from LF to CR-LF then the checksum
will always differ. Perhaps we need two entries for each file, with
and without CR-LF?
- I'm not sure how to put the files in place on MS-Windows if the
current user can't write in the $VIMRUNTIME directory. Create a .bat
file perhaps?
- If the user has local changes, they will be lost. We probably don't
care. Files that the user adds are left alone, but they can get
overwritten.
Comments are welcome.
--
CONCORDE: Message for you, sir.
He falls forward revealing the arrow with the note.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Manuel Ortega
Tony Mechelynck
differently (no "sudo" or "su" commands available), and the shell
script language is different too. I suppose that at least two versions
of the script will be necessary:
- Unix-like (Linux; Mac OS X; Windows with Cygwin or MinGW)
- MS-DOS-like (Windows without Cygwin or MinGW)
I suppose Mac OS 9 or earlier (which IIRC was not Unix-like) is not
supported anymore? (by Vim I mean)
rsync would also work (if the rsync server which used to serve the
patches is still running), but I don't remember if it is available for
Windows installations without Unix-like tools.
Best regards,
Tony.
Nikolay Aleksandrovich Pavlov
--
CONCORDE: Message for you, sir.
He falls forward revealing the arrow with the note.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Tony Mechelynck
<zyx...@gmail.com> wrote:
> 1. This is completely useless idea for *nix (both linux and mac) users […]
> 2. I think this is useless idea for Windows users as well [...]
On Linux, I think most users indeed either use their distro's Vim, or
compile their own from sources got by git or Mercurial, and that
runtime files are updated together with the executables.
On the Mac, there is the MacVim distribution, which is precompiled and
takes advantage of (IIUC) the Cocoa GUI. It used to be kept reasonably
up-to-date by Björn Winckler but see
https://groups.google.com/forum/#!topic/vim_mac/-bd5RKGs8qw (which I
haven't all read).
On Windows, there is Steve Hall's "Vim without Cream" distribution
https://sourceforge.net/projects/cream/files/Vim/ which lags a little
but is still being maintained when Steve thinks about it: the latest
versions there are 7.4.711, 7.4.827 and 7.4.977 (the latter less than
a week ago). This IMHO excellent distribution is made from official
sources but out of Bram's control and by means of a slightly different
build procedure which shouldn't affect the resulting Vim package once
it is installed. It also includes all the runtime files, up-to-date
for the build date
The problem here is that there are many Windows users who don't know
about the latter distribution, or if they do, who don't want to try
it, due to its low visibility on the official Vim download page
http://www.vim.org/download.php which OTOH prominently highlights Bram
distribution, which is not updated for individual patchlevels and thus
still is at 7.4.0.
Bram, IMHO the problem is not so much incompatible runtime files as a
lack of updates in general (runtimes and code) on the part of Windows
users. I believe that "Vim without Cream" (at the .../files/Vim/ URL
mentioned above) would deserve a mention near the top of the Vim
download page, and a mention which would say explicitly that it is
more up-to-date than yours. You may still say that it is a
"contributed build" if it puts you more at peace.
Best regards,
Tony.
Jonathan Newton
all runtime files. On linux, I build right from git, so again everything
is updated at once.
I think perhaps some confusion is due to users trying to get the latest
exe via the "vim without cream" link which only provides the binary and
not RT files. Perhaps the download page at vim.org should be amended to
make it more clear or to provide other alternatives.
Jonathan
[1] https://tuxproject.de/projects/vim/
Tony Mechelynck
[…]
> I think perhaps some confusion is due to users trying to get the latest exe
> via the "vim without cream" link which only provides the binary and not RT
> files. Perhaps the download page at vim.org should be amended to make it
> more clear or to provide other alternatives.
>
> Jonathan
>
> [1] https://tuxproject.de/projects/vim/
>
gvim-7-4-977.exe which is part of the latest set of "files" is not a
vim or gvim executable, it is a full installer, an NSIS installer
IIRC[1], which unzips the files it contains, including gvim.exe with
GUI, vim.exe with console interface, also IIUC the xxd executable, and
all the runtime files, and proceeds to install them where they belong.
See at https://sourceforge.net/projects/cream/ the following
paragraph:
UPDATE: Development has slowed recently due to the author's full time
endeavor to begin an architectural practice
(http://SteveHallArchitecture.com ). But the project still continues
to build gVim installers and add minor features and bug fixes in the
Cream source code.
If it were distributing only the gvim executable without runtime
files, there would be no use for an "installer".
[1] https://en.wikipedia.org/wiki/Nullsoft_Scriptable_Install_System
Best regards,
Tony.
Steve Hall
Tony Mechelynck
2.7 MB. I can't believe the difference is only due to the difference
between W32 and L64, especially since "Vim without Cream" has
+gettext/dyn +lua/dyn +multi_byte_ime/dyn +perl/dyn +python/dyn
+python3/dyn +ruby/dyn -tcl while I have +gettext +lua
+multi_byte+perl +python -python3 +ruby +tcl +xim all linked
statically.
Best regards,
Tony.
Nikolay Aleksandrovich Pavlov
Best regards,
Tony.
Ben Fritz
That all makes sense in a way, I suppose. But having a separate repository for just the runtime might make more sense.
Of course some runtime updates are incompatible with earlier versions of Vim, despite the authors' best efforts. So getting the whole dump to fix a problem in one file might occasionally cause unexpected issues. Better to just update all of Vim IMO.
> - If the $VIMRNTIME directory is not writable by the current user, put
> the updates in a temp directory and generate a shell script to move
> them into place. The have one "sudo" command to do the work.
I think this will not work in Windows for reasons below.
> - Rely on the netrw plugin to download the files.
>
I see this causing problems on Windows as well. I've never bothered downloading the required external tools for netrw to actually work for anything but local access on Windows, I'd guess many others are in the same boat.
Honestly if the solution requires a user to download an extra tool on Windows to allow them to download stuff, why not just have them install Mercurial/Git instead?
>
> Some things that might cause problems:
> - If the line endings are changed from LF to CR-LF then the checksum
> will always differ. Perhaps we need two entries for each file, with
> and without CR-LF?
Don't change line endings. Just distribute Unix-style and it will work on Windows, too. Frankly I'm annoyed it doesn't "just work" on Unix with either style like it does on Windows.
> - I'm not sure how to put the files in place on MS-Windows if the
> current user can't write in the $VIMRUNTIME directory. Create a .bat
> file perhaps?
I've never really had success with getting admin rights in a .bat file. Supposedly there is the "runas" command but I don't think provides what we want.
Really you'd either need to roll an .exe file/installer or tell the user to run an elevated command prompt. Telling an average user that will make their eyes glaze over. Although to be fair Vim users probably aren't "average" users in many ways.
> - If the user has local changes, they will be lost. We probably don't
> care. Files that the user adds are left alone, but they can get
> overwritten.
>
That's fair.
All in all, though, I think such a plugin would not be very useful for most people.
Steve Hall
Bram Moolenaar
Jonathan Newton wrote:
> On Windows, I keep vim updated via tuxproject builds [1], which include
> all runtime files. On linux, I build right from git, so again everything
> is updated at once.
an installer?
This page does not provide much help, I can't recomment giving this page
to a Vim beginner.
7zip is not a standard Windows tool, requiring to install another tool
makes it more difficult for the user.
> I think perhaps some confusion is due to users trying to get the latest
> exe via the "vim without cream" link which only provides the binary and
> not RT files. Perhaps the download page at vim.org should be amended to
> make it more clear or to provide other alternatives.
Perhaps using the wrong link?
> Jonathan
>
> [1] https://tuxproject.de/projects/vim/
--
Yah, well, we had to carve our electrons out of driftwood we'd
find. In the winter. Uphill. Both ways.
Bram Moolenaar
happen, we can fix it.
> > - If the $VIMRNTIME directory is not writable by the current user, put
> > the updates in a temp directory and generate a shell script to move
> > them into place. The have one "sudo" command to do the work.
>
> I think this will not work in Windows for reasons below.
>
> > - Rely on the netrw plugin to download the files.
>
> I see this causing problems on Windows as well. I've never bothered
> downloading the required external tools for netrw to actually work for
> anything but local access on Windows, I'd guess many others are in the
> same boat.
>
> Honestly if the solution requires a user to download an extra tool on
> Windows to allow them to download stuff, why not just have them
> install Mercurial/Git instead?
Windows system (I don't know what though) or include wget.exe. I have
one that is about 250 Kbyte. Only problem is that I don't know where it
came from, need to check if we can distribute it.
Including this is a good idea anyway, so you can just edit any file on
an ftp or web server "out of the box".
> > Some things that might cause problems:
> > - If the line endings are changed from LF to CR-LF then the checksum
> > will always differ. Perhaps we need two entries for each file, with
> > and without CR-LF?
>
> Don't change line endings. Just distribute Unix-style and it will work
> on Windows, too. Frankly I'm annoyed it doesn't "just work" on Unix
> with either style like it does on Windows.
endings on Windows. This is indeed inconsistent, especially when
updating with git.
I can give it a try to use LF on Windows and see what doesn't work.
There might be a few small problems, but it also solves problems.
> > - I'm not sure how to put the files in place on MS-Windows if the
> > current user can't write in the $VIMRUNTIME directory. Create a .bat
> > file perhaps?
>
> I've never really had success with getting admin rights in a .bat
> file. Supposedly there is the "runas" command but I don't think
> provides what we want.
>
> Really you'd either need to roll an .exe file/installer or tell the
> user to run an elevated command prompt. Telling an average user that
> will make their eyes glaze over. Although to be fair Vim users
> probably aren't "average" users in many ways.
the installer runs with extra priveleges. However, there is an answer
on stackoverflow that might work:
http://stackoverflow.com/questions/1894967/how-to-request-administrator-access-inside-a-batch-file/10052222#10052222
> > - If the user has local changes, they will be lost. We probably don't
> > care. Files that the user adds are left alone, but they can get
> > overwritten.
>
> That's fair.
>
> All in all, though, I think such a plugin would not be very useful for
> most people.
it all works perfectly... Dreaming?
--
Not too long ago, cut and paste was done with scissors and glue...
Bram Moolenaar
with building programs.
> 1. This is completely useless idea for *nix (both linux and mac) users
> because regular users will install Vim using a package manager and let
> package manager handle the updates (NOTE: many system package managers will
> not like it if you mess with $VIMRUNTIME). Developers following upstream
> are following upstream using a local clone of git or mercurial repository
> because version control systems provide far more advantages then such
> script or package manager (for the purpose of editing something in Vim
> sources, I do not mean that package managers are useless in front of
> repository existence).
Just don't use it. The command can do a check if the Runtime files are
in a place that's likely under control of the package manager and give a
warning.
On the other hand, if the provided packages are stale, this is a useful
way to update the runtime files without having to switch to building Vim
yourself (which requires figuring out the build options, not that easy
if you do it for the first time).
> 2. I think this is useless idea for Windows users as well because patches
> 7.N.xxx *do* add features, thus forcing users to choose packages which have
> latest Vim like vim without cream. Such packages, of course, contain
> up-to-date runtime. Updating just runtime here makes some sense, but I
> think that getting used to updating the whole Vim is better.
find the Vim installer he wants to use? They probably end up installing
Vim 7.4, just because that's the easiest to find. And that should be
fine, for most users the latests patches don't help them.
> In any case this is poor replacement for a proper package manager.
systems.
> About CRLF: LF endings work on Windows, do not them? Don’t change endings
> and you will be fine.
time :RuntimeUpdate runs it downloads all the files.
> About user changes: there is checksum. Use it to check installed files, in
> case it does not match leave user variant, creating {file.vim}.new.{a..z}
> (e.g. syntax/vim.vim.new.c on third update with user changes) nearby, abort
> update if all {file.vim}.new.{a..z} files exist, in any case give a
> warning. I think it is better then silently dropping user changes, but user
> should get an idea that changing standard files is a bad variant of
> handling things.
>
> About deletion: you do not know from which version to which update is
> performed. Just state that files in $VIMRUNTIME must *all* be files that
> are distributed with Vim. And delete everything which is in old CONTENTS,
> but not in new, assuming checksum matches with old. Give a warning for each
> file that is not in old CONTENTS or was edited.
overwrite changed files, because there is no need for the user to change
the files. However, dropping a few plugins in the $VIMRUNTIME/plugins
directory is OK, we can leave them alone.
We can first make an overview of what the command is going to do,
including giving a "CHANGED LOCALLY" warning, before actually making
changes. Although it should probably do its work without a prompt when
everything looks fine.
--
You were lucky to have a LAKE! There were a hundred and sixty of
us living in a small shoebox in the middle of the road.
Bram Moolenaar
Does github have an rsync endpoint? It's possible to put the files on
the ftp server, but that's another point of failure I would like to
avoid. Better use github as the "master".
Also, I would not want to mess with whatever the user has added to
$VIMRUNTIME. Sure, it's not supposed to happen, but not everybody reads
all the docs or understand how things work. Dropping a few plugins in
$VIMRUNTIME/plugins is not that unexpected. This is not so easy to
handle with rsync (unless you disable all deletes).
--
You had connectors? Eeee, when I were a lad we 'ad to carry the
bits between the computer and the terminal with a spoon...
Christian Brabandt
all. But perhaps setting the http_proxy variable would fix this for
wget.
Other than that, I like to have a runtime update command available.
Until now, I just replaced the vim.exe from tuxproject but did not
bother to update the runtime files, which has biten me once or twice.
>
> > > Some things that might cause problems:
> > > - If the line endings are changed from LF to CR-LF then the checksum
> > > will always differ. Perhaps we need two entries for each file, with
> > > and without CR-LF?
> >
> > Don't change line endings. Just distribute Unix-style and it will work
> > on Windows, too. Frankly I'm annoyed it doesn't "just work" on Unix
> > with either style like it does on Windows.
>
> Traditionally we have always distributed runtime files with CR-LF
> endings on Windows. This is indeed inconsistent, especially when
> updating with git.
>
> I can give it a try to use LF on Windows and see what doesn't work.
> There might be a few small problems, but it also solves problems.
would be to just always use LF for all platforms and not care about
CR+LF at all.
> > > - I'm not sure how to put the files in place on MS-Windows if the
> > > current user can't write in the $VIMRUNTIME directory. Create a .bat
> > > file perhaps?
> >
> > I've never really had success with getting admin rights in a .bat
> > file. Supposedly there is the "runas" command but I don't think
> > provides what we want.
> >
> > Really you'd either need to roll an .exe file/installer or tell the
> > user to run an elevated command prompt. Telling an average user that
> > will make their eyes glaze over. Although to be fair Vim users
> > probably aren't "average" users in many ways.
>
> We may need to include a small exe that runs the commands. Just like
> the installer runs with extra priveleges. However, there is an answer
> on stackoverflow that might work:
> http://stackoverflow.com/questions/1894967/how-to-request-administrator-access-inside-a-batch-file/10052222#10052222
(https://github.com/chrisbra/SudoEdit.vim). Haven't heard many
complaints from Windows users, although debugging and quoting gets
nasty.
> > > - If the user has local changes, they will be lost. We probably don't
> > > care. Files that the user adds are left alone, but they can get
> > > overwritten.
> >
> > That's fair.
> >
> > All in all, though, I think such a plugin would not be very useful for
> > most people.
>
> Best is to have something check for updates, click on "update now", and
> it all works perfectly... Dreaming?
Best,
Christian
--
Es liegt in der menschlichen Natur, vernünftig zu denken und unlogisch
zu handeln.
Nikolay Aleksandrovich Pavlov
> In any case this is poor replacement for a proper package manager.
True. Unfortunately we don't have a proper package manager for all
systems.
> About CRLF: LF endings work on Windows, do not them? Don’t change endings
> and you will be fine.
I'll have to check that. What I'm trying to avoid is that the first
time :RuntimeUpdate runs it downloads all the files.
> About user changes: there is checksum. Use it to check installed files, in
> case it does not match leave user variant, creating {file.vim}.new.{a..z}
> (e.g. syntax/vim.vim.new.c on third update with user changes) nearby, abort
> update if all {file.vim}.new.{a..z} files exist, in any case give a
> warning. I think it is better then silently dropping user changes, but user
> should get an idea that changing standard files is a bad variant of
> handling things.
>
> About deletion: you do not know from which version to which update is
> performed. Just state that files in $VIMRUNTIME must *all* be files that
> are distributed with Vim. And delete everything which is in old CONTENTS,
> but not in new, assuming checksum matches with old. Give a warning for each
> file that is not in old CONTENTS or was edited.
These two paragraphs contradict each other. I think it's OK to
overwrite changed files, because there is no need for the user to change
the files. However, dropping a few plugins in the $VIMRUNTIME/plugins
directory is OK, we can leave them alone.
h_east
2015-12-22(Tue) 5:44:27 UTC+9 Bram Moolenaar:
Vim body and the runtime files until now had been provided at the same time.
However, care must be taken a little When it comes to update only the runtime files.
If we use the new options or commands in runtime files, we will need to be strictly a check is made using the has() or exists() than ever.
Perhaps not to do so when the problem occurs frequently.
Thanks.
--
Best regards,
Hirohito Higashi (a.k.a h_east)
Gary Johnson
> On Di, 22 Dez 2015, Bram Moolenaar wrote:
>
> > Ben Fritz wrote:
> >
> > > On Monday, December 21, 2015 at 2:44:27 PM UTC-6, Bram Moolenaar wrote:
> > > > Some things that might cause problems:
> > > > - If the line endings are changed from LF to CR-LF then the checksum
> > > > will always differ. Perhaps we need two entries for each file, with
> > > > and without CR-LF?
> > >
> > > Don't change line endings. Just distribute Unix-style and it will work
> > > on Windows, too. Frankly I'm annoyed it doesn't "just work" on Unix
> > > with either style like it does on Windows.
> >
> > Traditionally we have always distributed runtime files with CR-LF
> > endings on Windows. This is indeed inconsistent, especially when
> > updating with git.
> >
> > I can give it a try to use LF on Windows and see what doesn't work.
> > There might be a few small problems, but it also solves problems.
>
> Please do. This has caused problems for me in the past and my opinion
> would be to just always use LF for all platforms and not care about
> CR+LF at all.
machines I use, Linux and Windows. Once I converted all the CR-LF
files to LF-only it has worked flawlessly.
Regards,
Gary
Jonathan Newton
On 12/22/2015 03:57 PM, Bram Moolenaar wrote:
> Jonathan Newton wrote:
>
>> On Windows, I keep vim updated via tuxproject builds [1], which include
>> all runtime files. On linux, I build right from git, so again everything
>> is updated at once.
> How do you do this? I thought this project provides the files but not
> an installer?
tuxproject build.
> This page does not provide much help, I can't recomment giving this page
> to a Vim beginner.
>
> 7zip is not a standard Windows tool, requiring to install another tool
> makes it more difficult for the user.
full set of files.
I guess the use case for :RuntimeUpdate is not clear to me. Do you
really want a user (perhaps inexperienced at that) to update only the
runtime files without updating the binary? It just seems less error
prone to update everything together.
Jonathan
James McCoy
> I guess the use case for :RuntimeUpdate is not clear to me. Do you really
> want a user (perhaps inexperienced at that) to update only the runtime files
> without updating the binary? It just seems less error prone to update
> everything together.
the runtime files shipped with Vim instead of just making more frequent
Vim releases?
Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jame...@jamessan.com>
Christian J. Robinson
> On Tue, Dec 22, 2015 at 08:09:47PM -0500, Jonathan Newton wrote:
>> I guess the use case for :RuntimeUpdate is not clear to me. Do you really
>> want a user (perhaps inexperienced at that) to update only the runtime files
>> without updating the binary? It just seems less error prone to update
>> everything together.
>
> Pretty much my thought, too. Why invent a whole new mechanism to update
> the runtime files shipped with Vim instead of just making more frequent
> Vim releases?
it's that there are far, far too few full Windows installer releases.
- Christian
--
Open mouth, Insert foot.
Christian J. Robinson <hep...@gmail.com> http://christianrobinson.name/
Jonathan Newton
How are the installer packages from vim.org produced? Could something be
setup to trigger production of these files at regular cadence?
Justin M. Keyes
> Ben Fritz wrote:
>> On Monday, December 21, 2015 at 2:44:27 PM UTC-6, Bram Moolenaar wrote:
> Yes, that is why we need to either use something available on every
> Windows system (I don't know what though) or include wget.exe. I have
> one that is about 250 Kbyte. Only problem is that I don't know where it
> came from, need to check if we can distribute it.
>
> Including this is a good idea anyway, so you can just edit any file on
> an ftp or web server "out of the box".
- it has a less restrictive license than wget
- development is very active
- it has many more features than wget
curl should have been included with the win32 Vim 10 years ago, it
would have enabled many more plugins to have network capabilities
without being broken on Windows.
>> > Some things that might cause problems:
>> > - If the line endings are changed from LF to CR-LF then the checksum
>> > will always differ. Perhaps we need two entries for each file, with
>> > and without CR-LF?
>>
>> Don't change line endings. Just distribute Unix-style and it will work
>> on Windows, too. Frankly I'm annoyed it doesn't "just work" on Unix
>> with either style like it does on Windows.
>
> Traditionally we have always distributed runtime files with CR-LF
> endings on Windows. This is indeed inconsistent, especially when
> updating with git.
>
> I can give it a try to use LF on Windows and see what doesn't work.
> There might be a few small problems, but it also solves problems.
Vundle, pathogen, vim-plug, neobundle, all would be broken on Windows:
they all pull the same plugin sources from GitHub.
>> > - I'm not sure how to put the files in place on MS-Windows if the
>> > current user can't write in the $VIMRUNTIME directory. Create a .bat
>> > file perhaps?
>>
>> I've never really had success with getting admin rights in a .bat
>> file. Supposedly there is the "runas" command but I don't think
>> provides what we want.
>>
>> Really you'd either need to roll an .exe file/installer or tell the
>> user to run an elevated command prompt. Telling an average user that
>> will make their eyes glaze over. Although to be fair Vim users
>> probably aren't "average" users in many ways.
>
> We may need to include a small exe that runs the commands. Just like
> the installer runs with extra priveleges. However, there is an answer
> on stackoverflow that might work:
provide up-to-date win32 binaries at vim.org.
>> All in all, though, I think such a plugin would not be very useful for
>> most people.
>
> Best is to have something check for updates, click on "update now", and
> it all works perfectly... Dreaming?
and automate-able middle ground.
---
Justin M. Keyes
Justin M. Keyes
>> 2015-12-21 23:44 GMT+03:00 Bram Moolenaar <Br...@moolenaar.net>:
> Please keep in mind that this feature is for users who are not familiar
> with building programs.
>
> Just don't use it. The command can do a check if the Runtime files are
> in a place that's likely under control of the package manager and give a
> warning.
>
> On the other hand, if the provided packages are stale, this is a useful
> way to update the runtime files without having to switch to building Vim
> yourself (which requires figuring out the build options, not that easy
> if you do it for the first time).
>
>> 2. I think this is useless idea for Windows users as well because patches
>> 7.N.xxx *do* add features, thus forcing users to choose packages which have
>> latest Vim like vim without cream. Such packages, of course, contain
>> up-to-date runtime. Updating just runtime here makes some sense, but I
>> think that getting used to updating the whole Vim is better.
>
> I don't agree. Ever looked over the shoulder of someone who tries to
> find the Vim installer he wants to use? They probably end up installing
> Vim 7.4, just because that's the easiest to find. And that should be
> fine, for most users the latests patches don't help them.
win32 binaries at vim.org would avoid the problem; whereas with the
extant inertia and lack of automation, there exists an invented
problem to be "solved" by providing a new :RuntimeUpdate command that,
I predict, will see as much (or rather, little) real-world usage as
GLVS and the Vim "bundle" concept.
Having observed many new users, and noting my own experience, I can
tell you that most users do not have any clue what "runtime" means in
the context of Vim. Providing a new :RuntimeUpdate command will be
totally confusing, if any user even happens to discover it: they will
expect it to update Vim itself, but instead they get some half-baked
solution that was already addressed 5 years ago by real-world
solutions in the form of Vundle, pathogen, Plug, and NeoBundle.
And meanwhile the vim.org win32 binaries will be stale.
---
Justin M. Keyes
Ben Fritz
I understand we have a few continuous integration build servers set up now.
Do they do a Windows build?
If so, instead of throwing away the result, could the build server create an installer with the result and make it available for download?
Bram Moolenaar
update command can use this to warn the user if his binary is outdated,
and only install the runtime files that match his version.
This can also function as a "check for updates" command. We can tell
the user where a new version can be downloaded. The NSIS installer
doesn't support updating, but we already have this as a
uninstall-then-install sequence.
It's a bit more work, possibly runtime files can include a version in
the header, so the script that generates the CONTENTS file can pick it
up.
--
I have to exercise early in the morning before my brain
figures out what I'm doing.
Bram Moolenaar
Justin M. Keyes wrote:
> On Tue, Dec 22, 2015 at 3:57 PM, Bram Moolenaar <Br...@moolenaar.net> wrote:
> > Ben Fritz wrote:
> >> On Monday, December 21, 2015 at 2:44:27 PM UTC-6, Bram Moolenaar wrote:
> > Yes, that is why we need to either use something available on every
> > Windows system (I don't know what though) or include wget.exe. I have
> > one that is about 250 Kbyte. Only problem is that I don't know where it
> > came from, need to check if we can distribute it.
> >
> > Including this is a good idea anyway, so you can just edit any file on
> > an ftp or web server "out of the box".
>
> curl is a better choice than wget because:
>
> - it has a less restrictive license than wget
> - development is very active
> - it has many more features than wget
>
> curl should have been included with the win32 Vim 10 years ago, it
> would have enabled many more plugins to have network capabilities
> without being broken on Windows.
work on Windows XP and up?
> These are contortions to avoid the actual solution, which is to
> provide up-to-date win32 binaries at vim.org.
> >> All in all, though, I think such a plugin would not be very useful for
> >> most people.
> >
> > Best is to have something check for updates, click on "update now", and
> > it all works perfectly... Dreaming?
>
> In the meantime, providing up-to-date win32 installers is a reasonable
> and automate-able middle ground.
--
Not too long ago, compress was something you did to garbage...
Bram Moolenaar
Jonathan Newton wrote:
> How are the installer packages from vim.org produced? Could something be
> setup to trigger production of these files at regular cadence?
machine. It might be possible to automate, but it's not easy.
E.g., you need the right diff.exe, Python installation, etc.
--
What the word 'politics' means: 'Poli' in Latin meaning 'many' and 'tics'
meaning 'bloodsucking creatures'.
Jonathan Newton
Jonathan Newton wrote:
> How are the installer packages from vim.org produced? Could something be
> setup to trigger production of these files at regular cadence?
It's a sequence of commands that need to be executed on a prepared
machine. It might be possible to automate, but it's not easy.
E.g., you need the right diff.exe, Python installation, etc.
Bram Moolenaar
Only the Windows build is involved.
Part of the work is to take the produced files and check that they
install properly on various systems, with or without an older version of
Vim.
--
LAUNCELOT: At last! A call! A cry of distress ...
(he draws his sword, and turns to CONCORDE)
Concorde! Brave, Concorde ... you shall not have died in vain!
CONCORDE: I'm not quite dead, sir ...
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
Nikolay Aleksandrovich Pavlov
Steve Hall
Nikolay Aleksandrovich Pavlov
On Wed, Dec 23, 2015 at 2:23 PM, Nikolay Aleksandrovich Pavlov <zyx...@gmail.com> wrote:>[...]> Vim without Cream definitely has some automation I think, don’t know> whether it is or can be public or not.I'm glad to share my scripts, but I think what we all want is a securesystem with only a very few fingers in the process. Frankly, myprocess would be automated if it was possible to post the files to SF.The host is the toughest part.
--Steve Hall [ digitect dancingpaper com ]Cream for Vim http://cream.SourceForge.net
Christian Brabandt
> The main reason why your scripts have such value is that they yield an
> installer. Hosting is much less of a problem: e.g. GH provides hosting and
> appveyor has http://www.appveyor.com/docs/deployment/github, there are other
> deployment options including pushing to ftp.
automatically pushed back to Github as binaries?
Any suggestions how the appveyor.yml should look like?
Best,
Christian
--
Männer wachen genauso gutaussehend auf, wie sie zu Bett gegangen
sind. Frauen dagegen scheinen sich über Nacht irgendwie zu verändern.
Steve Hall
Tony Mechelynck
<hep...@gmail.com> wrote:
> On Tue, 22 Dec 2015, James McCoy wrote:
>
>> On Tue, Dec 22, 2015 at 08:09:47PM -0500, Jonathan Newton wrote:
>>>
>>> I guess the use case for :RuntimeUpdate is not clear to me. Do you really
>>> want a user (perhaps inexperienced at that) to update only the runtime
>>> files
>>> without updating the binary? It just seems less error prone to update
>>> everything together.
>>
>>
>> Pretty much my thought, too. Why invent a whole new mechanism to update
>> the runtime files shipped with Vim instead of just making more frequent
>> Vim releases?
>
>
> I agree; the problem is not that it's hard to update runtime files, it's
> that there are far, far too few full Windows installer releases.
>
> - Christian
• for Linux every distribution includes a "reasonably" up-to-date Vim
(where the definition of "reasonably" is left to the distro in
question and where there are sometimes code changes and a system vimrc
not under Bram's control); compiling one's own Vim is not very hard.
As I'm on Linux myself, I have a couple of HowTo pages:
— http://vim.wikia.com/wiki/Getting_the_Vim_source_with_Mercurial :
this is for all platforms and doesn't change much; the latest change
was to mention the bitbucket Mercurial mirror of the github repository
when Bram's repo was moved there from the googlecode site
— http://users.skynet.be/antoine.mechelynck/vim/compunix.htm : this
describes how I compile Vim myself. AFAIK it is up-to-date; if it
doesn't work for you, be sure to let me know. Setting the configure
options by means of environmental variables defined in a script
"sourced" (not run) by the shell has the following advantages:
I don't modify the Makefile, so after creating as many shadow
directories as I want to compile different versions of Vim (at the
moment Huge and Tiny) I replace the copy in the Makefile in the
shadowdir by a link to ../Makefile which is then kept up-to-date by
Mercurial
if make decides to restart configure (admittedly it doesn't
happen now as often as it used to) the configure settings are still
the ones I want, even on the second run. Also, I need only set those
environment variables once in the konsole tab I use for building from
a given shadowdir (Mercurial for Vim runs in a different tab since it
has a different cuurent directory) and when a new changeset is pulled,
plain (make && make install || echo 'exit status' $?), with logging,
is enough to run the build. The featureset is set once and for all.
Of course, both "your distro's Vim" and "your own-compiled Vim" will
be of the 32- or 64-bit architecture appropriate for your OS and CPU.
• for Windows there is the "Vim without Cream" distribution, a 32-bit
distribution with gvim.exe, vim.exe and all runtime files, distributed
by means of an executable installer as is the custom on Windows. It
will run on both W32 systems and W64 with WOW64, which AFAIK means all
Windows installations. I recommend it to anyone who doesn't need to
edit very big files and use more than 2 GiB for Vim alone. As a point
of comparison my current gvim session (with 7 windows but no very big
files) uses only 13.9 MiB.
This distribution is not republished as often as it used to due to
Steve Hall's professional duties but it is still without comparison
with Bram's own 7.4.0 which dates back to 2013-08-10: in 2015 it has
been updated twice in February, twice in April, once in September and
once in December (a few days ago in fact).
The main problem with this distribution is that AFAIK it is not as
well-known as it deserves: too often I see Windows users reporting
bugs in 7.4.0 which have been fixed months or even years ago.
Best regards,
Tony.
Christian Brabandt
> On Do, 24 Dez 2015, Nikolay Aleksandrovich Pavlov wrote:
> > The main reason why your scripts have such value is that they yield an
> > installer. Hosting is much less of a problem: e.g. GH provides hosting and
> > appveyor has http://www.appveyor.com/docs/deployment/github, there are other
> > deployment options including pushing to ftp.
>
> So we need an adjustment to appveyor.yml to have Windows builts
> automatically pushed back to Github as binaries?
>
> Any suggestions how the appveyor.yml should look like?
solution.
Take the following appveyor file:
version: "{build}"
#skip_tags: true
environment:
matrix:
- ARCH: x64
- ARCH: x86
matrix:
fast_finish: true
os:
- Visual Studio 2015
build:
verbosity: minimal
before_build:
- '"C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd" /%ARCH% /release'
build_script:
- cd src
- sed -e "s/\$(LINKARGS2)/\$(LINKARGS2) | sed -e 's#.*\\\\r.*##'/" Make_mvc.mak > Make_mvc2.mak
- if "%ARCH%" == "x64" (nmake -f Make_mvc2.mak CPU=AMD64 GUI=yes FEATURES=HUGE IME=yes MBYTE=yes ICONV=yes DEBUG=no PYTHON_VER=27 DYNAMIC_PYTHON=yes PYTHON=C:\Python27-x64 PYTHON3_VER=34 DYNAMIC_PYTHON3=yes PYTHON3=C:\Python34-x64) else (nmake -f Make_mvc2.mak CPU=i386 GUI=yes FEATURES=HUGE IME=yes MBYTE=yes ICONV=yes DEBUG=no PYTHON_VER=27 DYNAMIC_PYTHON=yes PYTHON=C:\Python27 PYTHON3_VER=34 DYNAMIC_PYTHON3=yes PYTHON3=C:\Python34)
- .\gvim -u NONE -c "redir @a | ver | 0put a | wq!" ver.txt
- type ver.txt
after_build:
- copy *.exe ..\runtime\
- copy /Y xxd\*.exe ..\runtime
- mkdir ..\runtime\GvimExt
- copy /Y GvimExt\gvimext.dll ..\runtime\GvimExt\
- copy /Y GvimExt\README.txt ..\runtime\GvimExt\
- copy /Y GvimExt\*.inf ..\runtime\GvimExt\
- copy /Y GvimExt\*.reg ..\runtime\GvimExt\
- 7z a ..\gvim_%ARCH%.zip ..\runtime\*
test_script:
- cd testdir
- nmake -f Make_dos.mak VIMPROG=..\gvim
artifacts:
- path: gvim_x86.zip
name: gVim_x86
- path: gvim_x64.zip
name: gVim_x64
deploy:
- provider: GitHub
release: vim-$(APPVEYOR_REPO_TAG_NAME)
description: 'Nightly Vim Windows build snapshots'
auth_token:
secure: kH0D/3t+1Mc8OChKhe+voKlMO0aMwnlUr64QoZOJC6BaVwy+Us3ZHq9Oo+aBzjYc
artifact: /gVim/
draft: false
prerelease: false
appveyor-repo-tag: true
This creates x86 and x64 binaries and tests them using Visual Studio
2015. After all tests finish successfully, a zip file is created
containing the gvim.exe, xxd.exe, GvimExt and the runtime directory and
uploads it back to github.
I think, the Vim release from vim.org did bundle a diff.exe, but I don't
know how this was build, so this is not included.
The only interesting thing is, that one needs to generate a personal
access token at github for the repository, so that the binaries from
appveyor can be pushed back to github. A public_repo token is all that
is needed, after one is generated, copy and paste it to ci.appveyor.com
(login with your github account) and go to Encrypt data menu and encrypt
the token. The cipher then should be pasted back into the appveyor file
as secure auth_token (see above).
Binaries can bee seen here:
https://github.com/chrisbra/vim/releases/tag/vim-v7.4.979_test40
Appveyor Log is available here:
https://ci.appveyor.com/project/chrisbra/vim-fjfe9/build/62
(I had to test with several tags, which I removed later on, therefore, there are still some old zip files floating around).
(Note: I got failures on test86.out, so I removed those for testing)
Best,
Christian
Ken Takata
Great work!
But unfortunately some features are disabled:
* DirectWrite
* OLE
* Lua
* Perl
* Ruby
* Tcl
* Build *.mo files
* vim.exe
This batch file is for Windows SDK 7.1(=VC2010).
If you want to build with VC2015, you need to use another batch file.
This line should be:
on:
appveyor-repo-tag: true
Without 'on:', appveyor fails on compiling non-tagged version.
>
> This creates x86 and x64 binaries and tests them using Visual Studio
> 2015. After all tests finish successfully, a zip file is created
> containing the gvim.exe, xxd.exe, GvimExt and the runtime directory and
> uploads it back to github.
>
> I think, the Vim release from vim.org did bundle a diff.exe, but I don't
> know how this was build, so this is not included.
nsis/README.txt says that it can be found at:
http://www.mossbayeng.com/~ron/vim/diffutils.tar.gz
But the link is 404.
>
> The only interesting thing is, that one needs to generate a personal
> access token at github for the repository, so that the binaries from
> appveyor can be pushed back to github. A public_repo token is all that
> is needed, after one is generated, copy and paste it to ci.appveyor.com
> (login with your github account) and go to Encrypt data menu and encrypt
> the token. The cipher then should be pasted back into the appveyor file
> as secure auth_token (see above).
>
> Binaries can bee seen here:
> https://github.com/chrisbra/vim/releases/tag/vim-v7.4.979_test40
> Appveyor Log is available here:
> https://ci.appveyor.com/project/chrisbra/vim-fjfe9/build/62
>
> (I had to test with several tags, which I removed later on, therefore, there are still some old zip files floating around).
>
> (Note: I got failures on test86.out, so I removed those for testing)
This is caused by Python 2.7.11's bug.
See: https://github.com/vim/vim/issues/532
Executing the following commands solves this:
reg copy HKLM\SOFTWARE\Python\PythonCore\2.7 HKLM\SOFTWARE\Python\PythonCore\2.7-32 /s /reg:32
reg copy HKLM\SOFTWARE\Python\PythonCore\2.7 HKLM\SOFTWARE\Python\PythonCore\2.7-32 /s /reg:64
I have also enabled the following features:
* DirectWrite
* Lua (LuaBinaries 5.3.2)
* Perl (ActivePerl 5.22)
* Ruby (RubyInstaller 2.2.3)
* Tcl (ActiveTcl 8.6.4)
* Build *.mo files
* vim.exe
I haven't enabled the OLE feature, because when I enabled it, the built binary
didn't work on AppVeyor.
You can see the patches at here:
https://github.com/vim/vim/compare/master...k-takata:appveyor-release
The patches also include the following patches:
* https://github.com/vim/vim/issues/328#issuecomment-166502534
* https://groups.google.com/d/topic/vim_dev/vk-5rhFe_xw/discussion
You can see the result at here:
https://ci.appveyor.com/project/k-takata/vim/build/33
And you can see the binaries at here:
https://ci.appveyor.com/project/k-takata/vim/build/33/job/y6y8rr56ufnv834y/artifacts
https://ci.appveyor.com/project/k-takata/vim/build/33/job/xob8gv86jpkheqyl/artifacts
One more problem, gettext is not included. The official installer (gvim74.exe)
includes very old version of Taro Muraoka's Win32 porting from here:
http://sourceforge.net/projects/gettext/files/gettext-win32/0.10.35/
It doesn't have 64-bit version.
I'm considering to use Taro's latest MSVC porting:
https://github.com/koron/gettext
https://github.com/koron/libiconv
Regards,
Ken Takata
Christian Brabandt
On So, 27 Dez 2015, Ken Takata wrote:
> Hi Christian,
>
> Great work!
> But unfortunately some features are disabled:
> * DirectWrite
> * OLE
> * Lua
> * Perl
> * Ruby
> * Tcl
Is that the correct version? For ruby there are version 1.9.3 2.0.0
2.1.6 and 2.2.2 available. Which one would we need? tcl and lua do not
seem to be available on appveyor, which means I would have to install
them in the pre-build script I think. Do we really need those? Is OLE
really needed today?
> * Build *.mo files
Do we need those on Windows? How is this build and where are those files
put?
> * vim.exe
Do we need the console version as well?
Best,
Christian
--
Insider:
# kill -9 `ps -ax WinNT | cut -c 1-6`
Ken Takata
2015/12/28 Mon 0:53:53 UTC+9 Christian Brabandt wrote:
> Hi Ken!
>
> On So, 27 Dez 2015, Ken Takata wrote:
>
> > Hi Christian,
> >
> > Great work!
> > But unfortunately some features are disabled:
> > * DirectWrite
>
> What feature is this?
Please check v7.4.393.
Currently, DirectWrite (DirectX) is disabled by default, but I think it's
worth to be enabled by default.
This is also very useful when using GVim on a High DPI environment.
> > * OLE
> > * Lua
> > * Perl
> > * Ruby
> > * Tcl
>
> Hm, perl is available as version 5.20.1.2000 in x86. So no x64 version.
> Is that the correct version? For ruby there are version 1.9.3 2.0.0
> 2.1.6 and 2.2.2 available. Which one would we need? tcl and lua do not
> seem to be available on appveyor, which means I would have to install
> them in the pre-build script I think. Do we really need those? Is OLE
> really needed today?
I have install the languages in the 'before_build' phase:
https://github.com/k-takata/vim/blob/appveyor-release/src/appveyor.bat#L17-L40
I don't know whether OLE is needed, at least I don't use it. But the official
installer comes with OLE.
> > * Build *.mo files
>
> Do we need those on Windows? How is this build and where are those files
> put?
Yes, we need them. The official installer includes *.mo.
Please check this:
https://github.com/k-takata/vim/blob/appveyor-release/src/appveyor.bat#L110
And also:
https://groups.google.com/d/msg/vim_dev/vk-5rhFe_xw/Afk8HP-9CgAJ
> > * vim.exe
>
> Do we need the console version as well?
The official installer includes vim.exe.
(And I sometimes use vim.exe.)
Regards,
Ken Takata
Gary Johnson
> Is OLE really needed today?
Regards,
Gary
Bram Moolenaar
Ken Takata wrote:
> Great work!
> But unfortunately some features are disabled:
> * DirectWrite
> * OLE
> * Lua
> * Perl
> * Ruby
> * Tcl
> * Build *.mo files
> * vim.exe
> > I think, the Vim release from vim.org did bundle a diff.exe, but I don't
> > know how this was build, so this is not included.
>
> nsis/README.txt says that it can be found at:
> http://www.mossbayeng.com/~ron/vim/diffutils.tar.gz
> But the link is 404.
if needed. Likewise for other binaries that are not so easy to obtain.
e.g. gvimext64.dll.
[...]
to what's distributed, the ":Update" command could replace it. A
complication is that MS-Windows doesn't allow for running executables to
be replaced, like we can on Unix. Maybe there is a trick, such as
running a small program that starts Vim and exits. We also need to
handle those "features" that warn you from executing something that was
downloaded.
This should be simpler than downloading the installer and re-installing
everything. Unfortunately NSIS doesn't support updating.
--
'I generally avoid temptation unless I can't resist it."
-- Mae West
Nikolay Aleksandrovich Pavlov
Ken Takata wrote:
> Great work!
> But unfortunately some features are disabled:
> * DirectWrite
> * OLE
> * Lua
> * Perl
> * Ruby
> * Tcl
> * Build *.mo files
> * vim.exe
[...]
> > I think, the Vim release from vim.org did bundle a diff.exe, but I don't
> > know how this was build, so this is not included.
>
> nsis/README.txt says that it can be found at:
> http://www.mossbayeng.com/~ron/vim/diffutils.tar.gz
> But the link is 404.
It's included in the distribution files. I can add it to the git files,
if needed. Likewise for other binaries that are not so easy to obtain.
e.g. gvimext64.dll.
Christian Brabandt
complicated to download special releases for the build. One has to
update the URL every once in a while and I don't know, whether this is
worth the trouble.
I will update to use OLE and DIRECTX. From a first try, a +perl enabled
build did not link and so did the ruby versions 193 and 200 so I will
leave this out. And since this is only for daily Windows snapshots, I
think to provide a fully fledged language build is out of scope.
> I don't know whether OLE is needed, at least I don't use it. But the official
> installer comes with OLE.
version script is generated.
> > > * Build *.mo files
> >
> > Do we need those on Windows? How is this build and where are those files
> > put?
>
> Yes, we need them. The official installer includes *.mo.
> Please check this:
> https://github.com/k-takata/vim/blob/appveyor-release/src/appveyor.bat#L110
> And also:
> https://groups.google.com/d/msg/vim_dev/vk-5rhFe_xw/Afk8HP-9CgAJ
>
> > > * vim.exe
> >
> > Do we need the console version as well?
>
> The official installer includes vim.exe.
> (And I sometimes use vim.exe.)
Best,
Christian
--
Das wird sicher ein Spaß
-- Star Treck, Der erste Kontakt,
Christian Brabandt
On So, 27 Dez 2015, Bram Moolenaar wrote:
> It's included in the distribution files. I can add it to the git files,
> if needed. Likewise for other binaries that are not so easy to obtain.
> e.g. gvimext64.dll.
What is that used for? Is that for version 6.4?
reinstalling it, so I would not try to be too clever here.
Providing updated binaries should help most users and I don't think we
need a to provide a build with all features enabled. The most important
part is to include updated runtime files and binaries. One problem on my
Windows 10 system however is, that my system blocks the execution of
those provided binaries, since the distributor could not be verified (or
a similar error).
Well, I will try to improve the appveyor build slightly from the
feedback given here so lets see where this leads to.
Thanks for all the feedback, especially from Ken. I will try to address
those points and I am sure, Ken will update his version as well. So
hopefully we'll have an almost equivalent build by using appveyor.
Best,
Christian
Nikolay Aleksandrovich Pavlov
>
> I don't know whether OLE is needed, at least I don't use it. But the official
> installer comes with OLE.
That one worked, if you add a gvim -silent -register before the first
version script is generated.
> > > * Build *.mo files
> >
> > Do we need those on Windows? How is this build and where are those files
> > put?
>
> Yes, we need them. The official installer includes *.mo.
> Please check this:
> https://github.com/k-takata/vim/blob/appveyor-release/src/appveyor.bat#L110
> And also:
> https://groups.google.com/d/msg/vim_dev/vk-5rhFe_xw/Afk8HP-9CgAJ
Will check this one, thanks.
>
>
> > > * vim.exe
> >
> > Do we need the console version as well?
>
> The official installer includes vim.exe.
> (And I sometimes use vim.exe.)
Okay, I add the vim.exe as well.
Best,
Christian
--
Das wird sicher ein Spaß
-- Star Treck, Der erste Kontakt,
Ken Takata
2015/12/28 Mon 7:24:24 UTC+9 Christian Brabandt wrote:
> I will update to use OLE and DIRECTX. From a first try, a +perl enabled
> build did not link and so did the ruby versions 193 and 200 so I will
> leave this out. And since this is only for daily Windows snapshots, I
> think to provide a fully fledged language build is out of scope.
For +perl/dyn, I had to apply the following patch:
https://github.com/vim/vim/issues/328#issuecomment-166502534
This patch is needed when using VC2012 or earlier and ActivePerl 5.20 or later.
For +ruby/dyn:
RubyInstaller might be the most widely used Ruby distribution for Windows,
but it is built by MinGW, so we cannot normally link with it when compiling
Vim by MSVC. So I made some hacks to link with RubyInstaller. I had to get
Ruby's source code and generate config.h for MSVC, and adjusted some
variables.
Please check this:
https://github.com/k-takata/vim/blob/appveyor-release/src/appveyor.bat#L31-L37
and this:
https://github.com/k-takata/vim/blob/appveyor-release/src/appveyor.bat#L89-L92
> > I don't know whether OLE is needed, at least I don't use it. But the
official
> > installer comes with OLE.
>
> That one worked, if you add a gvim -silent -register before the first
> version script is generated.
Ah, thank you for the good information! I will try it later.
Regards,
Ken Takata
Christian Brabandt
https://github.com/chrisbra/vim/blob/appveyor-build/appveyor.yml
and
https://github.com/chrisbra/vim/blob/appveyor-build/src/appveyor.bat
It downloads your perl and gettext patches and builds x86 and x64 builds
GUI and console version, xxd.exe and GvimExt, the po-files and uploads
the build to https://github.com/chrisbra/vim/releases
I think only the diff.exe is missing now and possibly mzscheme support.
Note: for some reasons, the build is started twice and aborts the second
time. Don't know why yet.
Best,
Christian
--
Man hat immer zwei Gründe, etwas zu tun:
Einen anständigen und den wahren.
-- John Pierpont Morgan d.Ä.
Bram Moolenaar
Christian Brabandt wrote:
> On So, 27 Dez 2015, Bram Moolenaar wrote:
>
> > It's included in the distribution files. I can add it to the git files,
> > if needed. Likewise for other binaries that are not so easy to obtain.
>
> Can't you include and distribute the source?
source and build script.
> > e.g. gvimext64.dll.
>
> What is that used for? Is that for version 6.4?
"64" is 64 bits. Building it may require a specific compiler version.
> > Assuming we manage to produce a gvim.exe and/or vim.exe that is equivalent
> > to what's distributed, the ":Update" command could replace it. A
> > complication is that MS-Windows doesn't allow for running executables to
> > be replaced, like we can on Unix. Maybe there is a trick, such as
> > running a small program that starts Vim and exits. We also need to
> > handle those "features" that warn you from executing something that was
> > downloaded.
> >
> > This should be simpler than downloading the installer and re-installing
> > everything. Unfortunately NSIS doesn't support updating.
>
> From my experience, Windows users expect to close the application before
> reinstalling it, so I would not try to be too clever here.
updating.
> Providing updated binaries should help most users and I don't think we
> need a to provide a build with all features enabled. The most important
> part is to include updated runtime files and binaries. One problem on my
> Windows 10 system however is, that my system blocks the execution of
> those provided binaries, since the distributor could not be verified (or
> a similar error).
might have to build the executable installer and run that. The
":Update" command would then only check for a new version and possibly
download and execute it.
> Well, I will try to improve the appveyor build slightly from the
> feedback given here so lets see where this leads to.
the self-installing executable. Otherwise an update results in
different features.
> Thanks for all the feedback, especially from Ken. I will try to address
> those points and I am sure, Ken will update his version as well. So
> hopefully we'll have an almost equivalent build by using appveyor.
ARTHUR: Will you ask your master if he wants to join my court at Camelot?!
GUARD #1: But then of course African swallows are not migratory.
GUARD #2: Oh, yeah...
GUARD #1: So they couldn't bring a coconut back anyway...
The Quest for the Holy Grail (Monty Python)
Christian Brabandt
On Mo, 28 Dez 2015, Bram Moolenaar wrote:
>
> Christian Brabandt wrote:
>
> > On So, 27 Dez 2015, Bram Moolenaar wrote:
> >
> > > It's included in the distribution files. I can add it to the git files,
> > > if needed. Likewise for other binaries that are not so easy to obtain.
> >
> > Can't you include and distribute the source?
>
> Perhaps. I haven't built it myself, you would have to track down the
> source and build script.
> > > e.g. gvimext64.dll.
> >
> > What is that used for? Is that for version 6.4?
>
> This is for the "Edit with Vim" menu. It must match the OS version,
> "64" is 64 bits. Building it may require a specific compiler version.
>
> > > Assuming we manage to produce a gvim.exe and/or vim.exe that is equivalent
> > > to what's distributed, the ":Update" command could replace it. A
> > > complication is that MS-Windows doesn't allow for running executables to
> > > be replaced, like we can on Unix. Maybe there is a trick, such as
> > > running a small program that starts Vim and exits. We also need to
> > > handle those "features" that warn you from executing something that was
> > > downloaded.
> > >
> > > This should be simpler than downloading the installer and re-installing
> > > everything. Unfortunately NSIS doesn't support updating.
> >
> > From my experience, Windows users expect to close the application before
> > reinstalling it, so I would not try to be too clever here.
>
> Except that we use Vim to run the update script, thus it's running while
> updating.
checks, whether a new version is available and asks the user to manually
download it. Nothing fancy, it might automatically download the latest
release but would depend on the user to actually close Vim and extract
the zip manually.
>
> > Providing updated binaries should help most users and I don't think we
> > need a to provide a build with all features enabled. The most important
> > part is to include updated runtime files and binaries. One problem on my
> > Windows 10 system however is, that my system blocks the execution of
> > those provided binaries, since the distributor could not be verified (or
> > a similar error).
>
> But the gvim.exe installed with NSIS works? If that is true then we
> might have to build the executable installer and run that. The
> ":Update" command would then only check for a new version and possibly
> download and execute it.
Best,
Christian
--
Ich kann mir denken, daß ein reiner Dichter einen reinen Kaufmann
begreift und schätzt sogar; aber nicht umgekehrt.
-- Jean Paul
Ben Fritz
> >
> > Except that we use Vim to run the update script, thus it's running while
> > updating.
>
> Ah, I haven't thought about that. I rather thought, the :Update command
> checks, whether a new version is available and asks the user to manually
> download it. Nothing fancy, it might automatically download the latest
> release but would depend on the user to actually close Vim and extract
> the zip manually.
>
FWIW, that's exactly how the LibreOffice update check worked for me this week. :-)
Christian Brabandt
> Great work. With your help I updated the configuration like this:
> https://github.com/chrisbra/vim/blob/appveyor-build/appveyor.yml
> and
> https://github.com/chrisbra/vim/blob/appveyor-build/src/appveyor.bat
provided from https://mlocati.github.io/gettext-iconv-windows/ and this
works for both 32bit and 64bit builds. diff.exe is taken from gnuwin32
project: http://gnuwin32.sourceforge.net/packages/diffutils.htm
I haven't tried mzscheme support yet, but as far as I know, those builds
were broken on Windows anyhow
(https://groups.google.com/d/msg/vim_dev/g9XZskeNJSI/vgHccN0eAwAJ)?
I will keep posting updated builds on
https://github.com/chrisbra/vim/releases
Anybody wants to test those?
Best,
Christian
--
Das Halbwahre ist verderblicher als das Falsche.
-- Ernst von Feuchtersleben
Ken Takata
2015/12/31 Thu 19:54:46 UTC+9 Christian Brabandt wrote:
> On Mo, 28 Dez 2015, Christian Brabandt wrote:
>
> > Great work. With your help I updated the configuration like this:
> > https://github.com/chrisbra/vim/blob/appveyor-build/appveyor.yml
> > and
> > https://github.com/chrisbra/vim/blob/appveyor-build/src/appveyor.bat
>
> I updated the build script a little. Now it uses the gettext binaries
> provided from https://mlocati.github.io/gettext-iconv-windows/ and this
> works for both 32bit and 64bit builds. diff.exe is taken from gnuwin32
> project: http://gnuwin32.sourceforge.net/packages/diffutils.htm
I have added some changes based on your work.
https://github.com/k-takata/vim/commits/chrisbra-appveyor-build
Details are below.
1. About diff.exe
diff.exe from gnuwin32 is 32-bit binary, and it uses gettext and libiconv.
Doesn't it conflict with 64-bit builds? diff.exe bundled with the official
Vim 7.4 installer doesn't depend on gettext and libiconv, so I think using
diff.exe from gvim74.exe is safer.
Additionally, diff.exe is installed under the GvimExt directory, but it
should be installed to the same directory as gvim.exe.
https://github.com/k-takata/vim/commit/3624185df8c304669a6ad4a50d58dea6147cc0ac
2. Use shallow copy
Adding "shallow_clone: true" in appveyor.yml makes building a bit faster.
See: https://www.appveyor.com/docs/how-to/repository-shallow-clone#downloading-repository-via-github-or-bitbucket-api
https://github.com/k-takata/vim/commit/e26cd0e4beead2889704c164017d4961dcfc660b
3. Add "echo on" after Ruby's configure.bat
Echoing becomes off unintentionally after Ruby's configure.bat.
We couldn't see the command lines after that in AppVeyor's log.
Turn it on again.
https://github.com/k-takata/vim/commit/b3c7d55ec48691cb275e1c0679e53ee77f06d644
> I haven't tried mzscheme support yet, but as far as I know, those builds
> were broken on Windows anyhow
> (https://groups.google.com/d/msg/vim_dev/g9XZskeNJSI/vgHccN0eAwAJ)?
I haven't tried it either.
Next, I want to try to build installers on AppVeyor.
Regards,
Ken Takata
Bram Moolenaar
Ken Takata wrote:
> Happy New Year (in JST)!
> 2015/12/31 Thu 19:54:46 UTC+9 Christian Brabandt wrote:
> > On Mo, 28 Dez 2015, Christian Brabandt wrote:
> >
> > > Great work. With your help I updated the configuration like this:
> > > https://github.com/chrisbra/vim/blob/appveyor-build/appveyor.yml
> > > and
> > > https://github.com/chrisbra/vim/blob/appveyor-build/src/appveyor.bat
> >
> > I updated the build script a little. Now it uses the gettext binaries
> > provided from https://mlocati.github.io/gettext-iconv-windows/ and this
> > works for both 32bit and 64bit builds. diff.exe is taken from gnuwin32
> > project: http://gnuwin32.sourceforge.net/packages/diffutils.htm
>
> I have added some changes based on your work.
> https://github.com/k-takata/vim/commits/chrisbra-appveyor-build
>
> Details are below.
>
> 1. About diff.exe
>
> diff.exe from gnuwin32 is 32-bit binary, and it uses gettext and libiconv.
> Doesn't it conflict with 64-bit builds? diff.exe bundled with the official
> Vim 7.4 installer doesn't depend on gettext and libiconv, so I think using
> diff.exe from gvim74.exe is safer.
>
> Additionally, diff.exe is installed under the GvimExt directory, but it
> should be installed to the same directory as gvim.exe.
>
> https://github.com/k-takata/vim/commit/3624185df8c304669a6ad4a50d58dea6147cc0ac
There are many that won't work nicely. The diff.exe included in the
installer is an older version of GNU diffutils.
> 2. Use shallow copy
>
> Adding "shallow_clone: true" in appveyor.yml makes building a bit faster.
> See: https://www.appveyor.com/docs/how-to/repository-shallow-clone#downloading-repository-via-github-or-bitbucket-api
>
> https://github.com/k-takata/vim/commit/e26cd0e4beead2889704c164017d4961dcfc660b
>
>
> 3. Add "echo on" after Ruby's configure.bat
>
> Echoing becomes off unintentionally after Ruby's configure.bat.
> We couldn't see the command lines after that in AppVeyor's log.
> Turn it on again.
>
> https://github.com/k-takata/vim/commit/b3c7d55ec48691cb275e1c0679e53ee77f06d644
>
>
> > I haven't tried mzscheme support yet, but as far as I know, those builds
> > were broken on Windows anyhow
> > (https://groups.google.com/d/msg/vim_dev/g9XZskeNJSI/vgHccN0eAwAJ)?
>
> I haven't tried it either.
>
>
> Next, I want to try to build installers on AppVeyor.
move the files to the right place.
I was planning to improve the nsis install script, but didn't get to it
yet...
--
FATHER: You only killed the bride's father - that's all -
LAUNCELOT: Oh dear, I didn't really mean to...
FATHER: Didn't mean to? You put your sword right through his head!
LAUNCELOT: Gosh - Is he all right?
Christian Brabandt
>
> Ken Takata wrote:
>
> > Happy New Year (in JST)!
>
> Still a few hours away here...
You are not supposed to work today, but rather take a break.
Best,
Christian
--
Die Dichter sind gegen ihre Erlebnisse schamlos: Sie beuten sie aus.
-- Friedrich Wilhelm Nietzsche
Ken Takata
2016/1/1 Fri 4:10:22 UTC+9 Bram Moolenaar wrote:
> > 1. About diff.exe
> >
> > diff.exe from gnuwin32 is 32-bit binary, and it uses gettext and libiconv.
> > Doesn't it conflict with 64-bit builds? diff.exe bundled with the official
> > Vim 7.4 installer doesn't depend on gettext and libiconv, so I think using
> > diff.exe from gvim74.exe is safer.
> >
> > Additionally, diff.exe is installed under the GvimExt directory, but it
> > should be installed to the same directory as gvim.exe.
> >
> > https://github.com/k-takata/vim/commit/3624185df8c304669a6ad4a50d58dea6147cc0ac
>
> It's important that the diff program can handle different line endings.
> There are many that won't work nicely. The diff.exe included in the
> installer is an older version of GNU diffutils.
Sorry, I don't understand well...
Does the diff.exe included in the installer can handle different line endings?
Is the diff.exe enough for our purpose? Or do we need more up-to-date GNU
diffutils?
Regards,
Ken Takata
Bram Moolenaar
improvements from later versions. When building it with another
compiler or libraries it's possible to make it behave worse.
--
There can't be a crisis today, my schedule is already full.
Bram Moolenaar
I wrote:
> Ken Takata wrote:
>
> > 2016/1/1 Fri 4:10:22 UTC+9 Bram Moolenaar wrote:
> > > > 1. About diff.exe
> > > >
> > > > diff.exe from gnuwin32 is 32-bit binary, and it uses gettext and libiconv.
> > > > Doesn't it conflict with 64-bit builds? diff.exe bundled with the official
> > > > Vim 7.4 installer doesn't depend on gettext and libiconv, so I think using
> > > > diff.exe from gvim74.exe is safer.
> > > >
> > > > Additionally, diff.exe is installed under the GvimExt directory, but it
> > > > should be installed to the same directory as gvim.exe.
> > > >
> > > > https://github.com/k-takata/vim/commit/3624185df8c304669a6ad4a50d58dea6147cc0ac
> > >
> > > It's important that the diff program can handle different line endings.
> > > There are many that won't work nicely. The diff.exe included in the
> > > installer is an older version of GNU diffutils.
> >
> > Sorry, I don't understand well...
> > Does the diff.exe included in the installer can handle different line endings?
> > Is the diff.exe enough for our purpose? Or do we need more up-to-date GNU
> > diffutils?
>
> The diff.exe I have included works well. I don't expect useful
> improvements from later versions. When building it with another
> compiler or libraries it's possible to make it behave worse.
not to use an external diff program. Writing the temp files, invoking
diff and parsing the result has a lot of overhead.
There is a C# implementation that has a lot of comments, should be
possible to turn this into a C implementation that we can include in
Vim: http://www.mathertel.de/Diff/ViewSrc.aspx
Rewriting it means we can apply the Vim license and have no problems
distributing it. There are C implementations of diff, but they all
appear to be either hard to include in Vim or have license issues.
A few remarks:
- The Item struct has its equivalent as diff_T in Vim.
- The core algorithm works with an array of numbers. If done properly
we can use this for lines of text AND for differences between two
lines. This can improve the diff highlighting for changed lines.
- The Vim ex_diffupdate() function, where it calls diff_file() and
diff_read(), is where the algorithm would be invoked.
- The code can compare two files at a time, the code for handling 3 and
4 files already exists in Vim.
- We can probably drop all the code for writing the temp files and
reading back the diff. I don't think there is a diff program that
produces better results (and if there is, we should be able to update
the code).
- For short files or files with few differences we could run the
algorithm on every change to keep the diff updated, instead of the
workarounds that are currently in place. A simple solution would
measure the time it takes to run the algorithm and abort if it's
taking too long (with an option to set the timeout). And abort if the
user types.
Anyone who would like to work on this?
--
Life is a gift, living is an art. (Bram Moolenaar)
Ken Takata
2016/1/1 Fri 23:19:41 UTC+9 Bram Moolenaar wrote:
> Ken Takata wrote:
>
> > 2016/1/1 Fri 4:10:22 UTC+9 Bram Moolenaar wrote:
> > > > 1. About diff.exe
> > > >
> > > > diff.exe from gnuwin32 is 32-bit binary, and it uses gettext and libiconv.
> > > > Doesn't it conflict with 64-bit builds? diff.exe bundled with the official
> > > > Vim 7.4 installer doesn't depend on gettext and libiconv, so I think using
> > > > diff.exe from gvim74.exe is safer.
> > > >
> > > > Additionally, diff.exe is installed under the GvimExt directory, but it
> > > > should be installed to the same directory as gvim.exe.
> > > >
> > > > https://github.com/k-takata/vim/commit/3624185df8c304669a6ad4a50d58dea6147cc0ac
> > >
> > > It's important that the diff program can handle different line endings.
> > > There are many that won't work nicely. The diff.exe included in the
> > > installer is an older version of GNU diffutils.
> >
> > Sorry, I don't understand well...
> > Does the diff.exe included in the installer can handle different line endings?
> > Is the diff.exe enough for our purpose? Or do we need more up-to-date GNU
> > diffutils?
>
> The diff.exe I have included works well. I don't expect useful
> improvements from later versions. When building it with another
> compiler or libraries it's possible to make it behave worse.
OK, it seems better to keep using the diff.exe included in the gvim74.exe.
Now I succeeded in creating installers on AppVeyor.
Here are the scripts:
https://github.com/k-takata/vim/tree/chrisbra-appveyor-build
and the results:
https://ci.appveyor.com/project/k-takata/vim/build/65
(You can download the installers from the ARTIFACTS button.)
Differences from the gvim74.exe are:
1. Four types of packages
32-bit zip, installer
64-bit zip, installer
2. Compiler version
Windows SDK 7.1 (VC10)
3. Updated if_xx
ActivePerl 5.22
ActiveTcl 8.6
LuaBinaries 5.3
Python 2.7
Python 3.4
RubyInstaller 2.2
4. Updated libintl and libiconv
https://mlocati.github.io/gettext-iconv-windows/
Now libintl depends on libiconv.
Additionally, 64-bit version depends on libwinpthread.
There are still some problems:
1. 64-bit installer's default directory
64-bit installer will to install into "C:\Program Files (x86)\Vim", but
it should be "C:\Program Files\Vim".
2. Build time
It takes about 30 minutes that building 64- and 32-bit gvim.exe/vim.exe and
test them all on AppVeyor. I think it's enough to test only 64-bit gvim.exe
when building a non-tagged commit (as we currently do).
3. gvimext.dll in zip package
Which version of gvimext.dll should be included in the zip package?
64- or 32-bit? Both?
Regards,
Ken Takata
Bram Moolenaar
Would there be a stable URL to the latest build? Or would we need to
copy it elsewhere?
> Differences from the gvim74.exe are:
> 1. Four types of packages
> 32-bit zip, installer
> 64-bit zip, installer
build was useful. The outcome is still that the 32-bit build works for
everybody. It's simpler for users to not have to chose. I plan to only
distribute a 32-bit version.
> 2. Compiler version
> Windows SDK 7.1 (VC10)
> 3. Updated if_xx
> ActivePerl 5.22
> ActiveTcl 8.6
> LuaBinaries 5.3
> Python 2.7
> Python 3.4
> RubyInstaller 2.2
> 4. Updated libintl and libiconv
> https://mlocati.github.io/gettext-iconv-windows/
> Now libintl depends on libiconv.
> Additionally, 64-bit version depends on libwinpthread.
>
> There are still some problems:
> 1. 64-bit installer's default directory
> 64-bit installer will to install into "C:\Program Files (x86)\Vim", but
> it should be "C:\Program Files\Vim".
> 2. Build time
> It takes about 30 minutes that building 64- and 32-bit gvim.exe/vim.exe and
> test them all on AppVeyor. I think it's enough to test only 64-bit gvim.exe
> when building a non-tagged commit (as we currently do).
week would even be fine.
> 3. gvimext.dll in zip package
> Which version of gvimext.dll should be included in the zip package?
> 64- or 32-bit? Both?
being installed on.
--
Two cows are standing together in a field. One asks the other:
"So what do you think about this Mad Cow Disease?"
The other replies: "That doesn't concern me. I'm a helicopter."
Christian Brabandt
On Fr, 01 Jan 2016, Bram Moolenaar wrote:
> Building once per day should be sufficient. Picking a version every
> week would even be fine.
appveyor will automatically build a new release and upload it to
https://github.com/vim/vim/releases/tag/v7.5.XXXX
So users can automatically download whatever version they need.
Best,
Christian
--
In der Politik ist es wie in einem Konzert: Ungeübte Ohren halten
schon das Stimmen der Instrumente für Musik.
-- Amintore Fanfani
Bram Moolenaar
Ken Takata wrote:
[...]
> 3. Updated if_xx
> ActivePerl 5.22
> ActiveTcl 8.6
> LuaBinaries 5.3
> Python 2.7
> Python 3.4
> RubyInstaller 2.2
(since 2.7.11 has a problem).
Unfortunately, Vim can't load "python35.dll". I tried re-installing,
but that didn't help You mention Python 3.4, does 3.5 not work?
I'll stick to 3.4 for now, it appears to work.
I tried Ruby 2.2, but it appears it doesn't work with MSVC.
The config.h include file is in include/ruby-2.2.0/i386-mingw32.
Trying to change the path for that results in a missing "strings.h"
include file, I assume that's from MingW.
Hmm, all Ruby binaries appear to work only with MingW. Can't find one
to build with MSVC... I'll have to stick to Ruby 1.9.2 then.
I had not built with Lua, can't find instructions on how to do it.
I'm doing everything with 32 bit, in case that matters.
--
ARTHUR: Ni!
BEDEVERE: Nu!
ARTHUR: No. Ni! More like this. "Ni"!
BEDEVERE: Ni, ni, ni!
tux.
> I tried Ruby 2.2, but it appears it doesn't work with MSVC.
this mailing list:
https://groups.google.com/d/msg/vim_dev/P8l30hk9hyE/cG8wYjh3paMJ
Bram Moolenaar
I have never built Ruby on Windows, are there instructions to follow?
--
Michael: There is no such thing as a dump question.
Bernard: Sure there is. For example "what is a core dump?"
tux.
> I have never built Ruby on Windows, are there instructions to follow?
Ken Takata
2016/1/2 Sat 6:30:39 UTC+9 Bram Moolenaar wrote:
> Ken Takata wrote:
>
> [...]
>
> > 3. Updated if_xx
> > ActivePerl 5.22
> > ActiveTcl 8.6
> > LuaBinaries 5.3
> > Python 2.7
> > Python 3.4
> > RubyInstaller 2.2
>
> I'm updating my Windows machine with these. I'll use Python 2.7.10
> (since 2.7.11 has a problem).
>
> Unfortunately, Vim can't load "python35.dll". I tried re-installing,
> but that didn't help You mention Python 3.4, does 3.5 not work?
> I'll stick to 3.4 for now, it appears to work.
Before 3.4, pythonXX.dll was installed into the system directory
(C:\Windows\System32 or C:\Windows\SysWOW64), but after 3.5, python35.dll
is not installed into the system directory. So if you want to use 3.5,
you must add the python35.dll's directory to the PATH environment.
Using 3.4 is easier than 3.5.
> I tried Ruby 2.2, but it appears it doesn't work with MSVC.
> The config.h include file is in include/ruby-2.2.0/i386-mingw32.
> Trying to change the path for that results in a missing "strings.h"
> include file, I assume that's from MingW.
As I wrote in this post, I do some hacks on AppVeyor:
https://groups.google.com/d/msg/vim_dev/dAXpcpHmVw4/zz_NoTUICwAJ
1. Download Ruby 2.2's source code and generate config.h:
cd C:\projects
git clone https://github.com/ruby/ruby.git -b ruby_2_2
cd ruby
call win32\configure.bat
nmake .config.h.time
There is no need to build whole Ruby, just config.h is needed.
The config.h is generated in the .ext\include\i386-mswin32_100 directory.
2. Adjust some variables when building Vim
nmake -f Make_mvc.mak ^
... ^
RUBY=C:\projects\ruby DYNAMIC_RUBY=yes RUBY_VER=22 RUBY_VER_LONG=2.2.0 ^
RUBY_INSTALL_NAME=msvcrt-ruby$(RUBY_API_VER) ^
RUBY_PLATFORM=i386-mswin32_100 ^
RUBY_INC="/I $(RUBY)\include /I $(RUBY)\.ext\include\$(RUBY_PLATFORM)" ^
WINVER=0x500
Normally we need to set only RUBY, DYNAMIC_RUBY, RUBY_VER, RUBY_VER_LONG and
WINVER. (WINVER must be set to >=0x500, when building with Ruby 2.1+.)
But when using this trick, we also need to set RUBY_INSTALL_NAME,
RUBY_PLATFORM and RUBY_INC.
RUBY_PLATFORM becomes different value when you use different compiler.
E.g. If you use 64-bit VC2013 (=VC12), RUBY_PLATFORM is x64-mswin64_120.
When you build 64-bit version, RUBY_INSTALL_NAME must be set to
x64-msvcrt-ruby$(RUBY_API_VER). (Oops, I made a mistake in the appveyor.bat.)
With these tricks, Vim can use the dll from RubyInstaller.
> I had not built with Lua, can't find instructions on how to do it.
I use LuaBinaries (http://luabinaries.sourceforge.net/).
I downloaded lua-5.3.2_Win32_dllw4_lib.zip from the download page.
Regards,
Ken Takata
Ken Takata
Christian already answered this.
> > Differences from the gvim74.exe are:
> > 1. Four types of packages
> > 32-bit zip, installer
> > 64-bit zip, installer
>
> There have been many discussions in the past about whether a 64-bit
> build was useful. The outcome is still that the 32-bit build works for
> everybody. It's simpler for users to not have to chose. I plan to only
> distribute a 32-bit version.
OK.
I also use a 32-bit version on 64-bit Windows.
> > 2. Compiler version
> > Windows SDK 7.1 (VC10)
>
> Does this still run on Windows XP?
Yes, it does.
> > 3. Updated if_xx
> > ActivePerl 5.22
> > ActiveTcl 8.6
> > LuaBinaries 5.3
> > Python 2.7
> > Python 3.4
> > RubyInstaller 2.2
>
> All dynamically loaded?
Yes.
> > 4. Updated libintl and libiconv
> > https://mlocati.github.io/gettext-iconv-windows/
> > Now libintl depends on libiconv.
> > Additionally, 64-bit version depends on libwinpthread.
> >
> > There are still some problems:
> > 1. 64-bit installer's default directory
> > 64-bit installer will to install into "C:\Program Files (x86)\Vim", but
> > it should be "C:\Program Files\Vim".
> > 2. Build time
> > It takes about 30 minutes that building 64- and 32-bit gvim.exe/vim.exe and
> > test them all on AppVeyor. I think it's enough to test only 64-bit gvim.exe
> > when building a non-tagged commit (as we currently do).
>
> Building once per day should be sufficient. Picking a version every
> week would even be fine.
>
> > 3. gvimext.dll in zip package
> > Which version of gvimext.dll should be included in the zip package?
> > 64- or 32-bit? Both?
>
> Both. The installer picks the one appropriate for the system Vim is
> being installed on.
Regards,
Ken Takata
Christian Brabandt
> build was useful. The outcome is still that the 32-bit build works for
> everybody. It's simpler for users to not have to chose. I plan to only
> distribute a 32-bit version.
don't think it hurts, considering that appveyor builds it at almost no
additional costs.
Best,
Christian
--
Er war Geograph und Sie kannte auch keine Grenzen.
Bram Moolenaar
Ken Takata wrote:
> 2016/1/2 Sat 6:30:39 UTC+9 Bram Moolenaar wrote:
> > Ken Takata wrote:
> >
> > [...]
> >
> > > 3. Updated if_xx
> > > ActivePerl 5.22
> > > ActiveTcl 8.6
> > > LuaBinaries 5.3
> > > Python 2.7
> > > Python 3.4
> > > RubyInstaller 2.2
> >
> > I'm updating my Windows machine with these. I'll use Python 2.7.10
> > (since 2.7.11 has a problem).
> >
> > Unfortunately, Vim can't load "python35.dll". I tried re-installing,
> > but that didn't help You mention Python 3.4, does 3.5 not work?
> > I'll stick to 3.4 for now, it appears to work.
>
> Before 3.4, pythonXX.dll was installed into the system directory
> (C:\Windows\System32 or C:\Windows\SysWOW64), but after 3.5, python35.dll
> is not installed into the system directory. So if you want to use 3.5,
> you must add the python35.dll's directory to the PATH environment.
> Using 3.4 is easier than 3.5.
help. Unfortunately the only error is that the file can't be loaded,
there is no hint why. I suppose that even when the file is found there
can still be other reasons why it can't be loaded. Anyway, Python 3.4
is good enough.
Ruby directory, next to the MingW one? Or does that not work?
> RUBY_PLATFORM becomes different value when you use different compiler.
> E.g. If you use 64-bit VC2013 (=VC12), RUBY_PLATFORM is x64-mswin64_120.
>
> When you build 64-bit version, RUBY_INSTALL_NAME must be set to
> x64-msvcrt-ruby$(RUBY_API_VER). (Oops, I made a mistake in the appveyor.bat.)
>
> With these tricks, Vim can use the dll from RubyInstaller.
the best place for this is src/INSTALLpc.txt.
> > I had not built with Lua, can't find instructions on how to do it.
>
> I use LuaBinaries (http://luabinaries.sourceforge.net/).
> I downloaded lua-5.3.2_Win32_dllw4_lib.zip from the download page.
I spent too much time yesterday trying to do things that should be
simple, but turn out to be a big forest of options, choices and
failures. Some installers ask tons of questions that I don't know the
answer to. And now my $PATH is filled with directories that no longer
exist...
We should really have one place, with a nice step-by-step list of
instructions for every interface. Mainly for those who build Vim.
But there should also be a section for users, how to install the stuff
needed to run the interface. This should be in the help.
Since you have most of this figured out, can you please write this down?
And then have someone with a "clean" system follow them and check for
any missing pieces.
--
ARTHUR: Did you say shrubberies?
ROGER: Yes. Shrubberies are my trade. I am a shrubber. My name is Roger
the Shrubber. I arrange, design, and sell shrubberies.
Christian Brabandt
GSoC (google summer of code project, if we ever participate on one
again).
And I have suggested other ideas here:
https://groups.google.com/d/msg/vim_dev/AmMWxM0dIIA/CAwEplRRBM0J
Such ideas should be documented somewhere, so that people will find it
easier,
e.g. something like this:
http://vim.wikia.com/wiki/Vim_GSoC_2011_Ideas
(much of this still holds)
I have tried to log in to create a new page, but it seems wikia login
links do
not currently work. This is getting more and more unusable.
BTW: git has something similar:
https://git.wiki.kernel.org/index.php/SmallProjectsIdeas
Best,
Christian
Christian Brabandt
On Di, 05 Jan 2016, Christian Brabandt wrote:
> Such ideas should be documented somewhere, so that people will find
> it easier,
> e.g. something like this:
> http://vim.wikia.com/wiki/Vim_GSoC_2011_Ideas
> (much of this still holds)
> I have tried to log in to create a new page, but it seems wikia
> login links do
Best,
Christian
--
Es gibt kein Recht auf Faulheit in unserer Gesellschaft.
-- Gerhard Schröder
Ken Takata
I suppose you use 32-bit Vim on 64-bit Windows. If so, you should copy
python35.dll to C:\Windows\SysWOW64 (not System32). System32 is a system
directory for 64-bit programs, and SysWOW64 is for 32-bit programs.
If we copy ".ext\include\i386-mswin32_100\config.h" (when using 32-bit VC10)
to "C:\Ruby22\include\ruby-2.2.0\i386-mswin32_100\config.h", we don't need to
set RUBY_INC, but we still need to set RUBY_PLATFORM and RUBY_INSTALL_NAME.
Because:
1. The current Make_mvc.mak doesn't set RUBY_PLATFORM properly when using VC7
or later.
2. RUBY_INSTALL_NAME is used for the DLL name, and the name is different when
using different compiler. E.g.
MSVC10 32 bits: msvcr100-ruby220.dll
MinGW 32bits: msvcrt-ruby220.dll
MSVC10 64 bits: x64-msvcr100-ruby220.dll
MinGW 64bits: x64-msvcrt-ruby220.dll
We want to link Vim built by MSVC with RubyInstaller built by MinGW, so
RUBY_INSTALL_NAME must be set manually.
Now I'm trying to update Make_mvc.mak to set RUBY_PLATFORM properly,
but even if I succeeded this, we still need to set RUBY_INSTALL_NAME.
> > RUBY_PLATFORM becomes different value when you use different compiler.
> > E.g. If you use 64-bit VC2013 (=VC12), RUBY_PLATFORM is x64-mswin64_120.
> >
> > When you build 64-bit version, RUBY_INSTALL_NAME must be set to
> > x64-msvcrt-ruby$(RUBY_API_VER). (Oops, I made a mistake in the appveyor.bat.)
> >
> > With these tricks, Vim can use the dll from RubyInstaller.
>
> Can we please gather the complete, step-by-step instructions? Probably
> the best place for this is src/INSTALLpc.txt.
I need time for this.
> > > I had not built with Lua, can't find instructions on how to do it.
> >
> > I use LuaBinaries (http://luabinaries.sourceforge.net/).
> > I downloaded lua-5.3.2_Win32_dllw4_lib.zip from the download page.
>
> Well, then you have a .zip file. Then what?
OK, how about this:
X. Building with Lua support
============================
Vim with Lua support can be built with either MSVC or MinGW (or maybe Cygwin).
You can use binaries from LuaBinaries. (http://luabinaries.sourceforge.net/)
1) Download and install LuaBinaries
Go to the Download page of LuaBinaries:
http://luabinaries.sourceforge.net/download.html
Download lua-X.Y.Z_Win32_dllw4_lib.zip for x86 or
lua-X.Y.Z_Win64_dllw4_lib.zip for x64. You can use them both for MSVC and
MinGW.
Unpack it to a working directory. E.g. C:\projects\lua53.
Lua's header files will be installed under the include directory.
{{{ (This part is for users. Maybe it's better to move to if_lua.txt?)
Copy luaXY.dll to your Windows system directory. The system directory depends
on your Windows bitness and Vim bitness:
32-bit Vim on 32-bit Windows: C:\Windows\System32
32-bit Vim on 64-bit Windows: C:\Windows\SysWOW64
64-bit Vim on 64-bit Windows: C:\Windows\System32
Or another option is copying luaXY.dll to the directory where gvim.exe
(or vim.exe) is.
}}}
2) Build
You need to set LUA, DYNAMIC_LUA and LUA_VER.
LUA: Where Lua's header files are installed. E.g. C:\projects\lua53.
DYNAMIC_LUA: Whether dynamic linking is used. Set to yes.
LUA_VER: Lua version. E.g. 53 for Lua 5.3.X.
E.g. When using MSVC (as one line):
nmake -f Make_mvc.mak
LUA=C:\projects\lua53 DYNAMIC_LUA=yes LUA_VER=53
Or when using MinGW (as one line):
mingw32-make -f Make_mingw.mak
LUA=C:\projects\lua53 DYNAMIC_LUA=yes LUA_VER=53
> I spent too much time yesterday trying to do things that should be
> simple, but turn out to be a big forest of options, choices and
> failures. Some installers ask tons of questions that I don't know the
> answer to. And now my $PATH is filled with directories that no longer
> exist...
>
> We should really have one place, with a nice step-by-step list of
> instructions for every interface. Mainly for those who build Vim.
> But there should also be a section for users, how to install the stuff
> needed to run the interface. This should be in the help.
>
> Since you have most of this figured out, can you please write this down?
> And then have someone with a "clean" system follow them and check for
> any missing pieces.
I also need time for this.
Regards,
Ken Takata
Ken Takata
I wrote a patch for this.
After applying this patch, the following command:
nmake -f Make_mvc.mak ^
... ^
RUBY=C:\projects\ruby DYNAMIC_RUBY=yes RUBY_VER=22 RUBY_VER_LONG=2.2.0 ^
RUBY_INSTALL_NAME=msvcrt-ruby$(RUBY_API_VER) ^
RUBY_PLATFORM=i386-mswin32_100 ^
RUBY_INC="/I $(RUBY)\include /I $(RUBY)\.ext\include\$(RUBY_PLATFORM)" ^
WINVER=0x500
becomes simpler as the following:
nmake -f Make_mvc.mak ^
... ^
RUBY=C:\Ruby22 DYNAMIC_RUBY=yes RUBY_VER=22 RUBY_VER_LONG=2.2.0 ^
RUBY_MSVCRT_NAME=msvcrt ^
WINVER=0x500
(Assuming that the generated config.h has been copied to
"C:\Ruby22\include\ruby-2.2.0\i386-mswin32_100\config.h".)
Regards,
Ken Takata
Ken Takata
I have updated the appveyor scripts:
https://github.com/k-takata/vim/tree/chrisbra-appveyor-build
Changes from my previous mail(*) are:
(*) https://groups.google.com/d/msg/vim_dev/dAXpcpHmVw4/D_s6iwajAQAJ
* Sync with v7.4.1051.
* Fix that forgetting to set TCL_VER_LONG.
* Skip building x64 installer.
(x64 zip package is still created.)
This takes about 30 minutes.
* Build and test only x64 gvim.exe when a normal commit is pushed.
(Installers and zip packages are created only when a tag is pushed.)
This takes about 5 minutes.
Regards,
Ken Takata
Bram Moolenaar
--
The Law, in its majestic equality, forbids the rich, as well as the
poor, to sleep under the bridges, to beg in the streets, and to steal
bread. -- Anatole France
Ken Takata
2016/1/2 Sat 22:14:01 UTC+9 Bram Moolenaar wrote:
> Can we please gather the complete, step-by-step instructions? Probably
> the best place for this is src/INSTALLpc.txt.
I wrote it. Please review.
I also updated the appveyor script:
https://github.com/k-takata/vim/tree/chrisbra-appveyor-build
Regards,
Ken Takata
Olaf Dabrunz
It works, and I use it to reduce undo blocks on file reload to the
changes made in the reloaded file. It is also accessible to scripts.
My scripts use it every day.
It works on "string sequences", which is a thin layer that abstracts
access to buffer lines, lists of strings and characters in strings.
It also supports pushing a tokenizer in-between. The tokenizer code
includes a fast default tokenizer with some interesting properties,
and a regex-based tokenizer.
It should not be difficult to use it on a character-wise diff
between a pair of lines.
The only drop-in LCS implementation it currently works with causes
license issues.
I have been wanting to write an implementation of Myers' well-known LCS
algorithm which does not cause license issues, but this takes a bit of
time. I have been adapting LCS implementations for several purposes
already, this is part of my research projects.
Note that the existing diff tools that we all use every day bring in
heuristical speed improvements, and do pre- and postprocessing to
improve the results. These need to be included to achieve the same
level of quality.
My patch also includes the post-processing that we are used to expect,
but this must be re-written as well. And the pre-processing still needs
to be included.
I am also working on improving diff implementations / LCS algorithms for
software development, this is one of my core research and development
projects.
The improvements cannot be limited to work only from within an editor,
so they are first included in a stand-alone diff program.
For this reason, I would not drop support for parsing the output of an
external diff program, it could be worthwhile using it.
I also have an unfinished patch that implements parsing of the output of
a modified external diff program, to make an improved diff display. It
is unfinished and work in progress, and there are quirks, but in my vim
I already use it for all of my diff displays.
--
Olaf Dabrunz (oda <at> fctrace.org)
Olaf Dabrunz
> Note that the existing diff tools that we all use every day bring in
> heuristical speed improvements, and do pre- and postprocessing to
> improve the results.
regardless of whether any speedup heuristics are used in the comparison
itself.
Basically, the pre-processing makes arrangements to skip uninteresting
lines when comparing the texts, so that the relative weight of matches
between interesting lines increases, making it more likely to match-up
interesting lines.
The post-processing chooses between several same-weight solutions, and
tries to select a solution that is typically more likely to represent
the actual change.
Justin M. Keyes
What exactly do you mean by "license issues": is some part of the code
proprietary, or GPL?
---
Justin M. Keyes
Olaf Dabrunz
> On Sat, Jan 9, 2016 at 7:29 PM, Olaf Dabrunz <o...@fctrace.org> wrote:
> > On 09-Jan-16, Olaf Dabrunz wrote:
> >> Note that the existing diff tools that we all use every day bring in
> >> heuristical speed improvements, and do pre- and postprocessing to
> >> improve the results.
> >
> > To clarify: the pre- and post-processing improve the result of the diff,
> > regardless of whether any speedup heuristics are used in the comparison
> > itself.
> >
> > Basically, the pre-processing makes arrangements to skip uninteresting
> > lines when comparing the texts, so that the relative weight of matches
> > between interesting lines increases, making it more likely to match-up
> > interesting lines.
> >
> > The post-processing chooses between several same-weight solutions, and
> > tries to select a solution that is typically more likely to represent
> > the actual change.
>
> Olaf, what you describe is very exciting. Why not post a pull request?
A pull request would mean that licensing issues need to be resolved, so
parts of the code need to be re-written from scratch. Please see below.
> What exactly do you mean by "license issues": is some part of the code
> proprietary, or GPL?
-- LCS Implementation (The Core Algorithm)
The LCS implementation that I use at the moment, that is the core
algorithm of the diff, is a verbatim copy of a file from a GPL project.
This needs to be replaced with a different file under a different
license. I am not 100% sure (IANAL), but I believe the interface could
be re-used. It consists of a few #defines and a single function call.
I want to re-implement this from Myers' 1985 paper, and I have
implemented and analyzed LCS algorithms before, and adapted them for
research purposes (including Myers' famous algorithm).
The boundary conditions and corner cases need to be done right and
tested well. They are real brain teasers.
But
- It is difficult to ignore the additional ideas that went into the
GPL project's implementation of Myers' LCS algorithm, and which
contribute to the quality of its results. I have not seen any
papers published about these, so a re-implementation must probably
be based on a write-down of these ideas. They include:
- two optional speed heuristics, one is used by default: much
faster on larger files
- a simple way to create several instances of the algorithm for
the comparison of different kinds of sequences (not required
for vim though)
- pre- and post-processing stages that improve the diff results
-- these are not part of the core algorithm, but the
post-processing is included in my integration code, see below
- an elegant, readable and versatile implementation
I have already written descriptions of how these ideas work,
except for the pre-processing part.
But I fear that a re-implementation would be similar to the GPLed
implementation.
But I may be wrong. :)
- It takes time to implement this and to get it right, testing,
debugging ...
- Most of the other implementations I saw add ideas that are not
really helpful, at least not for our purposes. Some even add
unnecessary overhead. They are also more difficult to adapt or
re-use, some rely on features in some other implementation
language, and they are not as tried and tested.
That being said, the implementation Bram mentioned in his mail seems to
be worth a closer look. It may be the best re-implementation so far,
and may be a good basis for a C version.
But it should also include the speed heuristics and the pre- and post-
processing done in the GPLed project.
-- Vim Integration Code
The integration code is mostly written by me, aimed at inclusion in vim,
when usable for everyone. It also contains 100 - 150 lines of code
adapted from the GPL project (and about 2400 new lines of code, not
counting large comments). The GPLed parts need to be rewritten to make
all of it available under the vim license.
Also, the pre-processing needs to be implemented (and adapted to use my
"string sequences".)
I wrote the patch within one month last year, mainly because it was
there in my head and it eventually needed to get written. I also needed
a fast lcs() function for several reasons, I was using a Perl module
before that.
I do not think I should publish any of this unless I can publish all of
it under a palatable license, to avoid license confusion.
But since this keeps coming up, the purpose of my mail was to show that
there is work in progress here.
Also, it would be interesting to know what people here think about it,
and how the license issues should be sorted out.
By the way, I can also use the code as a back end for vim diff: the
patch implements the vim function lcs() that I can call from a small
vim script function that can be invoked by 'diffexpr'.
It works and is relatively fast, but since the pre-processing is not
implemented yet, calling aforementioned well-known diff program
still gives better results, at least in some cases.
Other than that, the lcs() interface exposes all configuration
options of the diff algorithm and the post-processing. And it adds
the optional tokenizer layer.
When the implementation is more complete (pre-processing included,
adapted code rewritten), a direct integration into vim's diff code
becomes interesting. Bram already noted that the LCS results can
directly be written into diff_T blocks. I have worked with diff_T
blocks for another patch (for my research project, see below), so I
do not expect any major problems with this part of the integration.
And my code already supports the comparison of buffer text and the
comparison of characters in two strings (read: comparison of two
lines).
The update strategy code needs to be added though, as noted by Bram:
keep calling the diff for every update, unless that takes too long,
then fall back on the faster workarounds.
I also have one or two ideas in that area.
-- Diff Research
The last part I was writing about is about proprietary research.
This is also not ready for publishing yet.
I mentioned this mainly to give Bram a reason to keep the code that
interfaces with an external diff program, because he said it could
probably be dropped.
If my research is any good, and the results look promising so far (and I
am already using the prototype for my daily work), then there will be
an external diff at some point and people may want to call it from vim.
Bram Moolenaar
Ken Takata wrote:
> Hi Bram and all,
>
> 2016/1/2 Sat 22:14:01 UTC+9 Bram Moolenaar wrote:
> > Can we please gather the complete, step-by-step instructions? Probably
> > the best place for this is src/INSTALLpc.txt.
>
> I wrote it. Please review.
improvements from there.
> I also updated the appveyor script:
> https://github.com/k-takata/vim/tree/chrisbra-appveyor-build
executable similar to what I made:
ftp://ftp.vim.org/pub/vim/pc/gvim74-1024.exe
That follows the instructions in the toplevel Makefile.
I have been looking at alternate installers. Main problem is that they
are completely different, thus it's not a matter of including parts of
them and understanding what changes. I'm a bit weary of making a
switch, I don't know what will stop working and the existing installer
works well on all systems that I know about (only that it looks outdated).
--
(letter from Mark to Mike, about the film's probable certificate)
I would like to get back to the Censor and agree to lose the shits, take
the odd Jesus Christ out and lose Oh fuck off, but to retain 'fart in
your general direction', 'castanets of your testicles' and 'oral sex'
and ask him for an 'A' rating on that basis.
Christian Brabandt
On So, 10 Jan 2016, Bram Moolenaar wrote:
>
> Ken Takata wrote:
>
> > Hi Bram and all,
> >
> > 2016/1/2 Sat 22:14:01 UTC+9 Bram Moolenaar wrote:
> > > Can we please gather the complete, step-by-step instructions? Probably
> > > the best place for this is src/INSTALLpc.txt.
> >
> > I wrote it. Please review.
>
> Great, thanks. Let me include this now. We can make further
> improvements from there.
>
> > I also updated the appveyor script:
> > https://github.com/k-takata/vim/tree/chrisbra-appveyor-build
>
> Where do we see the output of it? Does it produce the self-installing
> executable similar to what I made:
> ftp://ftp.vim.org/pub/vim/pc/gvim74-1024.exe
> That follows the instructions in the toplevel Makefile.
https://ci.appveyor.com/project/k-takata/vim/history e.g. last one seems
to be: https://ci.appveyor.com/project/k-takata/vim/build/81 then click
on an arch build and then on artifacts. I think the compiled builds are
then uploaded back there: https://github.com/k-takata/vim/releases
The instructions to build the binaries are here:
https://github.com/k-takata/vim/blob/chrisbra-appveyor-build/appveyor.yml
and especially
https://github.com/k-takata/vim/blob/chrisbra-appveyor-build/src/appveyor.bat
Mit freundlichen Grüßen
Christian
--
Lieber keine Spiegel, als jeden Morgen erschrocken.
Bram Moolenaar
Christian Brabandt wrote:
> On So, 10 Jan 2016, Bram Moolenaar wrote:
> >
> > Ken Takata wrote:
> >
> > > Hi Bram and all,
> > >
> > > 2016/1/2 Sat 22:14:01 UTC+9 Bram Moolenaar wrote:
> > > > Can we please gather the complete, step-by-step instructions? Probably
> > > > the best place for this is src/INSTALLpc.txt.
> > >
> > > I wrote it. Please review.
> >
> > Great, thanks. Let me include this now. We can make further
> > improvements from there.
> >
> > > I also updated the appveyor script:
> > > https://github.com/k-takata/vim/tree/chrisbra-appveyor-build
> >
> > Where do we see the output of it? Does it produce the self-installing
> > executable similar to what I made:
> > ftp://ftp.vim.org/pub/vim/pc/gvim74-1024.exe
> > That follows the instructions in the toplevel Makefile.
>
> I think it is here:
> https://ci.appveyor.com/project/k-takata/vim/history e.g. last one seems
> to be: https://ci.appveyor.com/project/k-takata/vim/build/81 then click
> on an arch build and then on artifacts. I think the compiled builds are
> then uploaded back there: https://github.com/k-takata/vim/releases
only need to do this once a day, if there are changes.
It does appear to use the distributed nsis/gvim.nsi file.
> The instructions to build the binaries are here:
> https://github.com/k-takata/vim/blob/chrisbra-appveyor-build/appveyor.yml
> and especially
> https://github.com/k-takata/vim/blob/chrisbra-appveyor-build/src/appveyor.bat
maintenance.
--
The most powerful force in the universe is gossip.
Christian Brabandt
have the compiled binaries available back at github.com/vim/vim/releases
So we could have users install whatever patch level they want.
>
> > The instructions to build the binaries are here:
> > https://github.com/k-takata/vim/blob/chrisbra-appveyor-build/appveyor.yml
> > and especially
> > https://github.com/k-takata/vim/blob/chrisbra-appveyor-build/src/appveyor.bat
>
> It contains quite a few version numbers. This will require regular
> maintenance.
get notifications for failures, so we notice as soon as a patch (or
upstream) breaks something.
Best,
Christian
--
Wer nachts gut schlafen will, muß tagsüber seine Ruhe haben.
Bram Moolenaar
it's most likely a patch I just submitted. However, for this build
script it depends on what other projects are doing, can happen any time.
I rather have someone other than me maintain this. And run it
separately from the existing continuous builds.
--
SOLDIER: What? Ridden on a horse?
ARTHUR: Yes!
SOLDIER: You're using coconuts!
Christian Brabandt
I tried to build but the nsis script failed.
Best,
Christian
--
Die deutsche Sprache sollte sanft und ehrfurchtsvoll zu den toten
Sprachen abgelegt werden, denn nur die Toten haben die Zeit, diese
Sprache zu lernen.
-- Mark Twain (eigl. Samuel Langhorne Clemens)
Ken Takata
2016/1/10 Sun 23:46:57 UTC+9 Bram Moolenaar wrote:
> Christian Brabandt wrote:
>
> > On So, 10 Jan 2016, Bram Moolenaar wrote:
> > >
> > > Ken Takata wrote:
> > >
> > > > Hi Bram and all,
> > > >
> > > > 2016/1/2 Sat 22:14:01 UTC+9 Bram Moolenaar wrote:
> > > > > Can we please gather the complete, step-by-step instructions? Probably
> > > > > the best place for this is src/INSTALLpc.txt.
> > > >
> > > > I wrote it. Please review.
> > >
> > > Great, thanks. Let me include this now. We can make further
> > > improvements from there.
> > >
> > > > I also updated the appveyor script:
> > > > https://github.com/k-takata/vim/tree/chrisbra-appveyor-build
> > >
> > > Where do we see the output of it? Does it produce the self-installing
> > > executable similar to what I made:
> > > ftp://ftp.vim.org/pub/vim/pc/gvim74-1024.exe
> > > That follows the instructions in the toplevel Makefile.
> >
> > I think it is here:
> > https://ci.appveyor.com/project/k-takata/vim/history e.g. last one seems
> > to be: https://ci.appveyor.com/project/k-takata/vim/build/81 then click
> > on an arch build and then on artifacts. I think the compiled builds are
> > then uploaded back there: https://github.com/k-takata/vim/releases
Thank you, Christian.
> Thanks. It builds lots of stuff, taking a lot of time. But we would
> only need to do this once a day, if there are changes.
I tried it, but it didn't succeed.
AppVeyor's build is triggered at every push to GitHub. We cannot trigger the
build once per a day. If we need such build cycle, we cannot use AppVeyor for
building installers, I think.
# Actually, I created a script to check if one day or more has been past since
# the last GitHub release.
# https://github.com/k-takata/vim/blob/appveyor-temp/src/check-gh-release.py
# But I couldn't skip creating a GitHub release when build is skipped.
# An empty GitHub release was created. :-(
> It does appear to use the distributed nsis/gvim.nsi file.
I did change nsis/gvim.nsi a bit:
https://github.com/vim/vim/compare/v7.4.1087...k-takata:33fe515#diff-809dbb3dbb145596bad833d733edebf5L6
* Added !ifndef .. !endif around VIMSRC, VIMRT and VIMTOOLS so that they can
be set from the command line.
* The SetCompressor command was appeared twice.
* Added libiconv-2.dll (and libwinpthread-1.dll for Win64) to use gettext
binaries from https://mlocati.github.io/gettext-iconv-windows/ .
Regards,
Ken Takata
Ken Takata
I understand your concern. But I don't think we need to update the scripts
frequently, maybe once or twice a year?
> I rather have someone other than me maintain this. And run it
> separately from the existing continuous builds.
Then, how about creating a special repository for building Win32 installer?
E.g. https://github.com/vim/vim-win32-installer
The problem is how to sync with the main repository (vim/vim).
It would be good if we could change the Travis CI setting of vim/vim and make
it automatically push a new change to the special repository.
(I don't know how to do it.)
Regards,
Ken Takata
Ben Fritz
> Then, how about creating a special repository for building Win32 installer?
> E.g. https://github.com/vim/vim-win32-installer
>
> The problem is how to sync with the main repository (vim/vim).
> It would be good if we could change the Travis CI setting of vim/vim and make
> it automatically push a new change to the special repository.
> (I don't know how to do it.)
>
Maybe a submodule/subrepository?
Ken Takata
2016/1/12 Tue 20:40:37 UTC+9 Christian Brabandt wrote:
> On Fr, 08 Jan 2016, Ken Takata wrote:
>
> > Hi Bram and all,
> >
> > 2016/1/2 Sat 22:14:01 UTC+9 Bram Moolenaar wrote:
> > > Can we please gather the complete, step-by-step instructions? Probably
> > > the best place for this is src/INSTALLpc.txt.
> >
> > I wrote it. Please review.
> >
> > I also updated the appveyor script:
> > https://github.com/k-takata/vim/tree/chrisbra-appveyor-build
>
> Here is an update to appveyor.bat to include mz_scheme/dyn
>
> I tried to build but the nsis script failed.
I found that it failed after 7.4.1083.
In our appveyor script, we use Windows SDK 7.1's setenv.bat to set environments,
not Visual Studio's vcvars32.bat.
The vcvars32.bat sets PLATFORM variable, but the setenv.bat sets TARGET_CPU
variable instead of PLATFORM.
The same problem can be occurred after 7.4.967 when the CPU variable is not
set explicitly.
The following patch fixes the problem:
--- a/src/GvimExt/Makefile
+++ b/src/GvimExt/Makefile
@@ -16,6 +16,9 @@ NODEBUG = 1
# On Windows NT
! ifndef CPU
CPU = i386
+! if !defined(PLATFORM) && defined(TARGET_CPU)
+PLATFORM = $(TARGET_CPU)
+! endif
! ifdef PLATFORM
! if ("$(PLATFORM)" == "x64") || ("$(PLATFORM)" == "X64")
CPU = AMD64
diff --git a/src/Make_mvc.mak b/src/Make_mvc.mak
index f51fbfc..6f0b843 100644
--- a/src/Make_mvc.mak
+++ b/src/Make_mvc.mak
@@ -216,6 +216,9 @@ CPU = i386
! endif
! else # !CPU
CPU = i386
+! if !defined(PLATFORM) && defined(TARGET_CPU)
+PLATFORM = $(TARGET_CPU)
+! endif
! ifdef PLATFORM
! if ("$(PLATFORM)" == "x64") || ("$(PLATFORM)" == "X64")
CPU = AMD64
Regards,
Ken Takata
Christian Brabandt
> The problem is how to sync with the main repository (vim/vim).
> It would be good if we could change the Travis CI setting of vim/vim and make
> it automatically push a new change to the special repository.
> (I don't know how to do it.)
available on github (since they would need to be run on the server
side).
I already maintain a script, that pushes all changes from the main
github/vim/vim repository to bitbucket/vim-mirror/vim repository. I
think, we could enhance it and push once a day, if a change was done to
a new repository.
One would have to trust me however and I can promise, that it will
eventually break one way or the other.
Best,
Christian
--
Wahrlich, keiner ist weise, der nicht das Dunkel kennt.
-- Hermann Hesse
Ken Takata
2016/1/12 Tue 20:40:37 UTC+9 Christian Brabandt wrote:
> On Fr, 08 Jan 2016, Ken Takata wrote:
>
> > Hi Bram and all,
> >
> > 2016/1/2 Sat 22:14:01 UTC+9 Bram Moolenaar wrote:
> > > Can we please gather the complete, step-by-step instructions? Probably
> > > the best place for this is src/INSTALLpc.txt.
> >
> > I wrote it. Please review.
> >
> > I also updated the appveyor script:
> > https://github.com/k-takata/vim/tree/chrisbra-appveyor-build
>
> Here is an update to appveyor.bat to include mz_scheme/dyn
>
> I tried to build but the nsis script failed.
I have updated the script. Here are the latest files:
https://github.com/k-takata/vim/blob/v7.4.1101-test2/src/appveyor.bat
https://github.com/k-takata/vim/blob/v7.4.1101-test2/appveyor.yml
Changes from v7.4.1101:
https://github.com/vim/vim/compare/v7.4.1101...k-takata:v7.4.1101-test2
Build history:
https://ci.appveyor.com/project/k-takata/vim/history
https://github.com/k-takata/vim/releases
Changes from your script are:
* Imported Yukihiro Nakadaira's latest patch (if_mzscheme6.diff).
* Use /S option to install Racket. No need to use 7-Zip.
* Install Racket to the default directory.
* Add the Racket/lib directory to the $PATH.
* Install some additional packeges for Racket.
Regards,
Ken Takata
Bram Moolenaar
for libintl-8.dll, since that one uses the iconv libraray. The one I
used so far was quite old.
Please let me know if this doesn't work and further changes are needed.
--
ALL: A witch! A witch!
WITCH: It's a fair cop.
ALL: Burn her! Burn her! Let's make her into a ladder.
Ken Takata
2016/1/17 Sun 2:06:17 UTC+9 Bram Moolenaar wrote:
> I am including the changes to gvim.nsi. I also updated the code to look
> for libintl-8.dll, since that one uses the iconv libraray. The one I
> used so far was quite old.
>
> Please let me know if this doesn't work and further changes are needed.
I think all the changes needed are fully merged. (except the build scripts)
How about this idea?
https://groups.google.com/d/msg/vim_dev/dAXpcpHmVw4/i6X-SqP1BAAJ
Maybe it's better to use git submodule.
If you like this, I will try it on my repository.
Regards,
Ken Takata
Bram Moolenaar
Building the gvim.exe once per day seems about right. Not sure how to
set that up. Perhaps some kind of automatic pull on the submodule?
We could just build on every commit, but I've already seen builds fail
because there are not sufficient resources.
--
hundred-and-one symptoms of being an internet addict:
1. You actually wore a blue ribbon to protest the Communications Decency Act.
Ken Takata
2016/1/20 Wed 1:48:07 UTC+9 Bram Moolenaar wrote:
> Ken Takata wrote:
>
> > Hi Bram,
> >
> > 2016/1/17 Sun 2:06:17 UTC+9 Bram Moolenaar wrote:
> > > I am including the changes to gvim.nsi. I also updated the code to look
> > > for libintl-8.dll, since that one uses the iconv libraray. The one I
> > > used so far was quite old.
> > >
> > > Please let me know if this doesn't work and further changes are needed.
> >
> > I think all the changes needed are fully merged. (except the build scripts)
> >
> > How about this idea?
> > https://groups.google.com/d/msg/vim_dev/dAXpcpHmVw4/i6X-SqP1BAAJ
> > Maybe it's better to use git submodule.
> > If you like this, I will try it on my repository.
>
> I'm not sure what that means...
>
> Building the gvim.exe once per day seems about right. Not sure how to
> set that up. Perhaps some kind of automatic pull on the submodule?
>
> We could just build on every commit, but I've already seen builds fail
> because there are not sufficient resources.
Okay, I set up another repository:
https://github.com/k-takata/vim-win32-installer
This includes the vim/vim repository as a submodule.
When a tag is pushed to the vim-win32-installer repository, an appveyor build
starts and built packages are uploaded to the release page:
https://github.com/k-takata/vim-win32-installer/releases
(Not to the release page of vim/vim.)
Build history is here:
https://ci.appveyor.com/project/k-takata/vim-win32-installer
Scripts for appveyor are here:
https://github.com/k-takata/vim-win32-installer/blob/master/appveyor.bat
https://github.com/k-takata/vim-win32-installer/blob/master/appveyor.yml
And here is a (sample) script for updating this repository:
https://github.com/k-takata/vim-win32-installer/blob/master/scripts/update-repo.sh
If this script is run once per day, gvim.exe will be built once per day.
Maybe it's better to run on Christian's server.
How about this?
And how about creating github.com/vim/vim-win32-installer repository?
Regards,
Ken Takata
Bram Moolenaar
make most people happy. I think the only hint that's needed is "in case
you don't have a preference, download the "_x86.exe" file and run it".
Once in a while I can take one of the builds and put it on ftp.vim.org
and link to it directly from the download page. This would be the
"stable version". It will never be the latest, since it takes a few
days to make sure that there are no regressions.
> Build history is here:
> https://ci.appveyor.com/project/k-takata/vim-win32-installer
>
> Scripts for appveyor are here:
> https://github.com/k-takata/vim-win32-installer/blob/master/appveyor.bat
> https://github.com/k-takata/vim-win32-installer/blob/master/appveyor.yml
>
> And here is a (sample) script for updating this repository:
> https://github.com/k-takata/vim-win32-installer/blob/master/scripts/update-repo.sh
>
> If this script is run once per day, gvim.exe will be built once per day.
> Maybe it's better to run on Christian's server.
>
> How about this?
> And how about creating github.com/vim/vim-win32-installer repository?
How To Keep A Healthy Level Of Insanity:
4. Put your garbage can on your desk and label it "in".
Ken Takata
OK, I added a note:
https://github.com/k-takata/vim-win32-installer/releases
I think it's ready to set up the official installer repository. ;-)
Regards,
Ken Takata