--
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.
Best regards,
Tony.
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.
> 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.
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)
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?
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.
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
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
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
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.
>
> 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,
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
FWIW, that's exactly how the LibreOffice update check worked for me this week. :-)
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
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
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
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
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
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
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
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
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
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
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
Maybe a submodule/subrepository?
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
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
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
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
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