Compiling Neovim MacOS dependency path issue

[andrewcrook]

I have compiled Neovim stable for macOS and installed it into its own directory.

When I check the paths its still using the .deps directory in the source code path ($HOME/Developer/neovim)

Shouldn’t make install have moved these a long with Neovim into CMAKE_INSTALL_PREFIX (~/.local/nvim)?

You can see the paths from within nvim.

I presume these paths are compiled into nvim at build time?

:lua print(package.path)

./?.lua;/Users/XXXX/Developer/neovim/.deps/usr/share/luajit-2.1/?.lua;/usr/local/share/lua/5.1/?.lua;/usr/local/share/lua/5.1/?/init.lua;/Users/XXXX/Developer/neovim/.deps/usr/share/lua/5.1/?.lua;/Users/XXXX/Developer/neovim/.deps/usr/share/lua/5.1/?/init.lua

:lua print(package.path)

./?.so;/usr/local/lib/lua/5.1/?.so;/Users/XXXX/Developer/neovim/.deps/usr/lib/lua/5.1/?.so;/usr/local/lib/lua/5.1/loadall.so

[andrewcrook]

Oof, it probably should but I suspect this is going to be hard to fix properly with our current build setup.

Thanks for verifying dundargoc

[andrewcrook]

I also noticed that the precompiled macOS download uses /Users/Runner probably also wrong?
I suppose that I can override package.path and package.cpath at runtime.

[bfredl]

There might be an extra bullshit paths added in addition, but are any expected runtime files actually missing from the installed PREFIX path (which also gets included into 'runtimepath') ?

[andrewcrook]

using

:lua print(vim.inspect(vim.api.nvim_list_runtime_paths()))

{ "/Users/XXXX/.config/nvim", "/Users/XXXX/.local/share/nvim/lazy/lazy.nvim", "/Users/XXXX/.local/share/nvim/lazy/nvim_rocks", "/Users/XXXX/.local/share/nvim/lazy/cmp-nvim-lsp", "/Users/XXXX/.local/share/nvim/lazy/null-ls.nvim", "/Users/XXXX/.local/share/nvim/lazy/nvim-lspconfig", "/Users/XXXX/.local/share/nvim/lazy/mason-null-ls.nvim", "/Users/XXXX/.local/share/nvim/lazy/mason-lspconfig.nvim", "/Users/XXXX/.local/share/nvim/lazy/mason.nvim", "/Users/XXXX/.local/nvim/share/nvim/runtime", "/Users/XXXX/.local/nvim/share/nvim/runtime/pack/dist/opt/matchit", "/Users/XXXX/.local/state/nvim/lazy/readme", "/Users/XXXX/.local/share/nvim/lazy/cmp-nvim-lsp/after” }

They all seem to exist and checkhealth passes
I renamed .deps in the source folder to .deps.bak and it still works.

The .deps/build/downloads folder in the source folder after building contains

libtermkey
libuv
libvterm
lua-compat-5.3
luajit
luarocks
luv
msgpack
treesitter
treesitter-c
treesitter-lua
treesitter-query
treesitter-vim
treesitter-vimdoc
unibilium

I wonder if .deps is only used for the build process?
and, as you say, the paths are just leftovers from the build.

looking at :version it certainly seems that the .deps was used in building and compiling neovim.

:version

NVIM v0.9.4
Build type: RelWithDebInfo
LuaJIT 2.1.1692716794
Compilation: /opt/homebrew/opt/ccache/libexec/cc -O2 -g -Og -g -Wall -Wextra -pedantic -Wno-unused-
parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wvla -Wdouble-promotion -Wmissing-n
oreturn -Wmissing-format-attribute -Wmissing-prototypes -Wimplicit-fallthrough -fdiagnostics-color=
always -fstack-protector-strong -DUNIT_TESTING -DINCLUDE_GENERATED_DECLARATIONS -I/Users/XXXX/Dev
eloper/neovim/.deps/usr/include/luajit-2.1 -I/opt/homebrew/opt/gettext/include -I/Users/XXXX/Deve
loper/neovim/.deps/usr/include -I/Users/XXXX/Developer/neovim/build/src/nvim/auto -I/Users/XXXX
/Developer/neovim/build/include -I/Users/XXXX/Developer/neovim/build/cmake.config -I/Users/XXXX
/Developer/neovim/src -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Develo
per/SDKs/MacOSX14.2.sdk/usr/include -I/Users/XXXX/Developer/neovim/.deps/usr/include -I/Users/XX
XX/Developer/neovim/.deps/usr/include -I/Users/XXXX/Developer/neovim/.deps/usr/include -I/Users/
XXXX/Developer/neovim/.deps/usr/include -I/Users/XXXX/Developer/neovim/.deps/usr/include -I/Use
rs/XXXX/Developer/neovim/.deps/usr/include

[clason]

Yes, .deps is only used in the build process (which leverages the built nvim binary for later stages). Ideally, the paths should be removed before installing, but that is non-trivial and low priority as these paths have not (yet) been identified as harmful.

[andrewcrook]

Many thanks @clason @bfredl @dundargoc