The source for setting the path is slightly different, so relax the
search/replace term, so it works with the new version.
Fixes starting the web-preview process.
I've been working for a long time towards automatic nix dependencies for
neovim plugins (using luarocks rockspecs to discover the said
dependencies).
This is an initial commit to help me complete the missing bits.
buildNeovimPluginFrom2Nix is right now a placeholder which helps me test
in my fork a version that does a flat install of luarocks.
the vim updater will now check for attributes with the same name in the lua package set,
if that's the case the script will generate buildNeovimPluginFrom2Nix.
This simplifies usages and makes the default value consistent.
In a few cases, the default value was interpreted to be `false`,
but this is useless, because virtually nobody will explicitly
set `allowAliases = true;`.
The current wrapper only includes vim, gvim and the man pages
(optionally). This rewrite distinguishes two scenarios, which I expect
cover the majority of use cases:
- standalone mode, when `name != "vim"`, means the user already has a
vim in scope and only wants to add a customized version with a
different name. In this case we only include wrappers for `/bin/*vim`.
- non-standalone mode, when `name == "vim"`, means the user expects a
normal vim package that uses the specified configuration. In this case
we include everything in the original derivation, with wrappers for
all the executables that accept a vimrc.
update.py and its companion update-shell.nix need to know where they are, else
they can't find the root default.nix of Nixpkgs. Because of this, I further
added a small piece of documentation about those path-dependent pieces of code.
nixpkgs creates a hierarchy of 3 folders share/runtime/<PKG_NAME> for no reason ?
makes debugging harder as well as paths longer when patching so this
removes this nested folders.
Now it's possible to use in an overlay `guiSupport` set to `false`
(boolean) and doing so will disable many X related dependencies from
being used and the closure would be reduced automatically - Close#116716.
`vimPackage` may not have a version attribute if it was specified using
a full name instead, such as with a `buildEnv` call. This can happen
right now on Darwin when `vimPackage` is `macvim.configure {…}`.
continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
In the current Vim, the Python support can be implemented by linking to
the Python library, e.g., lib/libpython3.8.dylib on darwin. The
previous workaround of wrapping Vim to prefix $PATH is not sufficient
anymore. Since in the current Vim, the Python interpreter is no longer
invoked, but instead, the dynamically linked library is used, in which
only the original Python modules are loaded, causing plugins to fail
to load their required Python modules.
Experiments show that, however, it is controlled by the $NIX_PYTHONPATH
environment variable. In this commit, we add the required environment
variable to the wrapped Vim workaround as previously proposed. So that
the Vim plugins can use Python modules in the specified Python derivation.
When building MacVim with nix-daemon it tries to place the derived data
into a path rooted in `/var/empty`, which fails. Specifying the derived
data path ourselves fixes this problem.
vim_configurable and neovim have both supported a mechanism to build
them with a custom vimrc that supports plugins from Nix. This updates
MacVim to support the same sort of configuration using an expression
like
macvim.configure {
customRC = ''
# custom configuration goes here
'';
packages.myVimPackage = with pkgs.vimPlugins; {
start = [ youcompleteme fugitive ];
opt = [ phpCompletion elm-vim ];
}
}
Once configured, .override will allow for editing the configuration.
Like vim_configurable and neovim, configuring macvim does not require
rebuilding it. Also like them, configuring macvim turns off the user
vimrc file.
Since we're not using the Nix compiler, our buildInputs aren't
automatically exposed to the compiler, which means it was actually
compiling against system libncurses instead of Nix libncurses.
Also remove the `-Wno-error` from the make flags (and the unnecessary
`PREFIX` definition) in favor of using a much more targeted error
suppression at the configure flags. This works around an issue where
implicit function definitions are considered an error and the configure
script was trying to compile a file tht invoked an ncurses function
without including the relevant header.
MacVim compiles the Vim part using `/usr/bin/clang` and the GUI part
using Xcode. The Xcode portion always uses Xcode's own SDK and we have
no workable alternative. The Vim portion so far has been compiling using
a hybrid compilation environment, where it uses the SDK for most stuff
but picks up a bunch of library linker paths (including libSystem) by
virtue of Ruby's LDFLAGS. This hybrid compilation environment meant that
if the SDK headers referenced a symbol that the library itself didn't
have, this could produce link errors.
Previously we attempted to fix this by synthesizing an include path that
contained just the one header from Nix's Libsystem that referenced the
missing symbol, to get rid of the reference and allow linking to work
again, but this was very hacky and runs the risk of future Xcode SDK
changes producing the same errors with different headers, or of future
SDK versions expecting the intercepted header to contain a definition
that Nix's doesn't.
This new approach is to just clean up the compilation environment such
that the Vim portion is compiling against the Xcode SDK as well, by
sanitizing the LDFLAGS produced by the configure script so it stops
referencing Nix's versions of OS libraries. This means the resulting Vim
binary no longer depends at runtime on Nix for anything except the
scripting language support, but that's how it's been for the MacVim
binary all along anyway, and this approach should keep us insulated
against future Xcode SDK changes.
Xcode 11.4 has an updated sys/_types/_fd_def.h header that references a
new symbol from libSystem. This is a problem because we're using
`/usr/bin/clang` to compile the non-Xcode portion, and this pulls in
headers from Xcode's SDK. Somehow it's still linking to the Nix
libraries (I can't figure out where configure finds these to put into
`LDFLAGS` as we're not using the cc-wrapper). The end result is we get a
linker error where this new symbol can't be found at link time, even
though it's a weak import and isn't required at runtime.
Ideally we'd provide a full 10.12 SDK to `/usr/bin/clang`, but we can't
do that because even the DevSDK package we use for our 10.12 SDK doesn't
contain everything (in particular it's missing nearly all dylibs) so we
just get linker errors if we do that.
Instead we'll just do a horrible hack and provide an `-isystem` path to
a folder structure that contains only the 10.12 `sys/_types/_fd_def.h`
header. This avoids the new symbol without causing all the errors that
happen if we pull in the entire `${darwin.Libsystem}/include`.
We were adding this to the compilation of MacVim, but not to the
compilation of the separate Vim binary. We may not actually need it for
MacVim at all, but omitting it for the Vim binary meant our postInstall
phase would fail for some people.
Fixes#73514
