It's been a while since I did this, so .... lets see what happens.
For starters we have this setup
- Windows 10 64 bit
- using VS code (with some cmake and C++/C extensions installed)
- installed cmake manually
- I'm doing this off two different computers, so these notes will not have output :S
Just to establish that we have everything we need to build neovim, I'm going to take the long route using cmake by hand and avoiding the usual shortcuts used in the default instructions.
From the VS Code terminal (powershell) I'm doing the following, in the neovim src dir (> is the prompt)
> mkdir .deps > cd .deps > cmake ../third-party > cmake --build .
Things get interesting on that last step
- some project is trying to call the MS compiler with options like -g -O3 -fPIC, apparently those are being ignored
- unibilium failed to build with 'git apply: bad git-diff on line 27' you can skip the patch by commenting the path command lines in BuildUnibilium.cmake
- likewise patching fails for libtermkey
For libtermkey it seems the later patch (concerning the escape sequences) fails to apply, or rather it is considered to be > corrupt. More importantly it is not clear to me what is the intent of the that patch command
- first it calls git init
- then it calls apply for the patchfiles
maybe the intention was to setup a git index in order to be able to reapply patches. I'm not sure 'git init' is supposed to > work for this, but in my system this does not seem to work. I'm also seeing some unexpected behaviour from git-apply - I was expecting it to remove all changes if they do not apply, instead the modified files are kept. In any case this type of use of git can also be found in other places. More importantly it seems running build twice will always fail, because a patch cannot be applied twice.
As luck would have it we really dont need those patches, so I'm gonna just wing it by disabling the unibilium patch command and commenting out the second libtermkey patch. Anyway lets retry to build deps after those changes.
> cmake --build . --target clean > cmake --build .
This should build all the dependencies for you. They will be stored in .deps/usr. Whats is happening here is that there is a second cmake project in third-party that builds neovim dependencies, and by convention we place them in .deps. The main project cmake settings will look for the dependencies in that folder.
Now lets build neovim, by going back to the root folder and ...
> cd .. > mkdir build > cd build > cmake .. > cmake --build .
As usual you should now be able to run
Some important points:
- I think cmake picked the 32bit compiler, more on this later
- I choose to build third-party dependencies manually, some recipes in the wiki do this for you
- there is something wrong going on with patch command for third-party
- the second libtermkey is actually not needed at all, it just addresses the tests
- not sure about the unibilium, but it does build :)
Now for 64bit builds
And now for 64 bit mode. It is basically the same process, just need to set the proper generator.
First clean up all you did before
> rm .deps > rm build
Now lets repeat all that came before for 64bit builds. First dependencies,
> mkdir .deps > cd .deps > cmake -G "Visual Studio 15 2017" ../third-party > cmake --build .
now for neovim
> cd .. > mkdir build > cd build > cmake -G "Visual Studio 15 2017" .. > cmake --build .
There you go. You can check the binary type the intended one, using objdump or dumpbin, or even notepad if you can read binary (the PE header is actually readable).
Time to fix those patch issues
- i cannot reproduce this on linux
- for starters we can test with unibilium since it does not depend on other components
Lets try the following
> mkdir .deps > cd .deps > cmake ../third-party > cmake --build . --target unibilium