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
This allows full filesystem access except for Homebrew. This is because
we don't know where Xcode will be installed so we can't just whitelist
it and its dependencies.
This fixes several Xcode 11 incompatibilities with MacVim, including an
issue where it wasn't inheriting the deployment target correctly to
begin with.
It seems that /usr/bin/ibtool marks stdin/stdout/stderr as nonblocking,
which can cause the subsequent build phase to fail when it tries to
write to stdout. I don't know why this problem just started happening
for me, but preventing ibtool from inheriting fds fixes the problem.
Fix up the macvim package to build again, with the latest snapshot. The
patchfile has been recreated by manually reapplying all of the changes
from the old patchfile, and the other changes in here were figured out
by trial and error (such as the need to unset `LD`).
Also tweak the package to use python37 by default, and add an option to
go back to python27 if desired.
Disable Sparkle so the user isn't prompted to update a readonly package.
Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
Undefined symbols for architecture x86_64:
"_OBJC_CLASS_$_NSArray", referenced from:
objc-class-ref in os_macosx.o
ld: symbol(s) not found for architecture x86_64
Using gtk + darwin support seems broken at the moment, we probably want
guiSupport = "carbon" instead but that doesn't work and something like
macvim is probably better for that. This fixes the build while keeping
guiSupport enabled which might be desirable for eg. +clientserver.
Fixes#45025
As suggested by @jtojnar in GitHub issue #44580, this patch adds the
package `wrapGAppsHook` to the dependencies (specifically, the
`nativeBuildInputs`) of `vim_configurable`, when `vim_configurable` is
built against GTK 3.
This change prevents GVim from crashing if one tries to use its
file-choosing dialog, and fixes a warning that otherwise might be
emitted if one tries to use its find/replace dialog.
Use `stdenv.mkDerivation` directly instead of `composableDerivation`.
Some configure flags may have changed as the conversion wasn't exactly
straightforward.
Use `stdenv.mkDerivation` directly instead of `composableDerivation`.
Some configure flags may have changed as the conversion wasn't exactly
straightforward.
It seems as Python will be fetched from $PATH in Vim 8.1:
```
stat("/home/ma27/bin/python", 0x7ffe57a317b0) = -1 ENOENT (No such file or directory)
stat("/run/wrappers/bin/python", 0x7ffe57a317b0) = -1 ENOENT (No such file or directory)
stat("/home/ma27/.nix-profile/bin/python", 0x7ffe57a317b0) = -1 ENOENT (No such file or directory)
stat("/nix/var/nix/profiles/default/bin/python", 0x7ffe57a317b0) = -1 ENOENT (No such file or directory)
stat("/run/current-system/sw/bin/python", {st_mode=S_IFREG|0555, st_size=291, ...}) = 0
readlink("/run/current-system/sw/bin/python", "/nix/store/ggjkqbvwnv7dflkmdgmmp"..., 4096) = 72
```
This breaks in cases where you want to use a modified Python derivation
for the VIM plugins you use in `vim_configurable`:
```
let
vim_configurable' = vim_configurable.override {
# python with modules for ensime
python = python.withPackages (ps: with ps; [ sexpdata websocket_client ]);
};
in
vim_configurable'.customize {
# ...
}
```
With VIM 8.0 this worked perfectly fine, now it's necessary to install
the modified `python` in $PATH to actually use it, otherwise an error
like this arises:
```
[ensime] A dependency is missing, please `pip2 install sexpdata websocket-client` and restart Vim.
Press ENTER or type command to continue
```
However it should be possible to pass the modified Python to the
modules, the easiest workaround is to write a wrapper which prefixes
$PATH to have the Python derivation available.
* Never modify tabstop. This causes incompatibilities with other
utilities that expect tabs to always be 8 spaces.
* Add standard boilerplate for system-level filetype plugins.
Semi-automatic update generated by https://github.com/ryantm/nix-update tools.
This update was made based on information from https://repology.org/metapackage/vim/versions.
These checks were done:
- built on NixOS
- ran `/nix/store/j6w96w36f0naab7fffqri1cmspaa3mnb-vim-8.0.1655/bin/vim -h` got 0 exit code
- ran `/nix/store/j6w96w36f0naab7fffqri1cmspaa3mnb-vim-8.0.1655/bin/vim --help` got 0 exit code
- ran `/nix/store/j6w96w36f0naab7fffqri1cmspaa3mnb-vim-8.0.1655/bin/vim --version` and found version 8.0.1655
- found 8.0.1655 with grep in /nix/store/j6w96w36f0naab7fffqri1cmspaa3mnb-vim-8.0.1655
- directory tree listing: https://gist.github.com/b65f9cb4045c205c8c3ee68503c42596
Semi-automatic update generated by https://github.com/ryantm/nix-update tools. These checks were done:
- built on NixOS
- ran `/nix/store/5afa788kqasx65plvzwjnffq9ihzdbmn-vim-8.0.1605/bin/vim -h` got 0 exit code
- ran `/nix/store/5afa788kqasx65plvzwjnffq9ihzdbmn-vim-8.0.1605/bin/vim --help` got 0 exit code
- ran `/nix/store/5afa788kqasx65plvzwjnffq9ihzdbmn-vim-8.0.1605/bin/vim --version` and found version 8.0.1605
- found 8.0.1605 with grep in /nix/store/5afa788kqasx65plvzwjnffq9ihzdbmn-vim-8.0.1605
- directory tree listing: https://gist.github.com/f9af564ba8cc53b90d1d262c2e786eee
* remove EOL ruby versions for security and maintenance reasons.
* only expose ruby_MAJOR_MINOR to the top-level. we don't provide
guarantees for the TINY version.
* mark all related packages as broken
* switch the default ruby version from 2.3.x to 2.4.x
This update contains a lot of fixes that are too much to be summarized
here, so here is the upstream changelog (basically "git log"):
https://github.com/vim/vim/commits/v8.0.1250
The main reason for this bump is that I got annoyed by a bug that was
fixed in upstream version 8.0.1194, which caused a race condition during
vim startup when it's trying to retrieve background colors from the
terminal.
Sometimes it could happen that random commands are executed at Vim
startup (typically pasting the "" buffer) and after bisecting I've found
out that version 8.0.1194 indeed fixed this problem.
The reason why I'm updating to version 8.0.1250 is that when looking
through the Git log it contains a whole lot of fixes but no new
features, so I'd assume it's safe to upgrade.
I've tested all packages that depend on Vim and they still succeed
building. In addition to that I've used the new version for a couple of
hours without any issue.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @lovek323, @LnL7, @vaibhavsagar
This doesn't change any defaults; I suspect that dropping gtk2 support
would annoy some people so I didn't want to do that without asking
around first.
- fix wrongly used *native* build inputs;
- remove confusing `prePatch = "cd src";` ;
- adapt RPATH handling to multiple-output changes;
- don't list full compiler flags in vim --version,
as that would keep references to -dev paths.
Together, the closure of the default feature-set drops almost by 100 MB.
The lean vim attribute would *not* lose any references due to patching
--version, so we only apply it for vim_configurable.
In the [discussion](https://github.com/NixOS/nixpkgs/pull/18801) of this pull
request @LnL7 was unable to complete a darwin build because the
python_framework.patch does not apply and suggests it should be removed.
Instead of explicitly stating "I want version 3" or "I want version 2"
you now simply specify what the python argument will be, and
vim_configurable will set up the flags for you. config.vim.python must
be set, still.
In 6f08fdd26, I left in a typo after copying from my `~/.nixpkgs/config`.
I would normally test this out locally, but I'm fixing up my conf locally,
and, in the interest of not forgetting to push this change up, made the edit
through GitHub's UI.
Oops.
This updates macvim to 7.4.648. This also fixes the build, which was broken when I set the default Ruby version to 2.2.2 (one of the symbols was renamed).
I don't see a reason for having wrapVim function and vimWrapper and
vimHugeXWrapper packages. If you need a system vimrc, whats wrong with
``environment.etc."vimrc".text`` ?
Also strictly speaking ``vimHugeXWrapper`` didn't wrap, X-version
properly. I.e. running ``gvim`` have console vim version.
MacVim's maintenance has stagnated, so this moves `macvim` to a new maintainer.
Additionally, the `-headerpad_max_install_names` linker flag is passed to
prevent problems when setting the rpaths.
It seems Vim needs to be instructed how to scan for the begining
of the multiline statements to correctly and efficiently highlight
lanuages.
See :help syn-sync-maxlines
Instead of applying all of the patches, this build pulls an archive from
the source code repo with all of the patches already applied. This is the
preferred way from http://www.vim.org/sources.php
- vim-nox: client-server implementation without X
- latest: latest mercurial sources (still very stable)
- default: latest release
vim-plugins: Introduce an area to put vim plugins which are worth adding to nix
because they need more effort than just "unpacking". Document that
dependencies with it. (I should never link ld.so with a NIX_LDFLAGS -rpath
forced)
I made vim, scummvm cross-build. I added prboom (that cross-builds).
Mplayer and elinks don't cross-build fine still, but are on the way.
The mplayer fails to build in a weird way; nix does not show either a gcc
error message or even the 'make' error message.
svn path=/nixpkgs/branches/stdenv-updates/; revision=23131
applyAndFun has a bug resulting in the same arg beeing added more than
once when using a concatenating merge function for the attr set.
I've tried giving the function a name "overridableDelayableArgs" which
resembles its usage much more.
important refactoring:
applyAndFun had .fun and .funMerge only when passing the merge
function lib.mergeOrApply
composableDerivation {
initial = {
...
};
}
to
overridableDelayableArgs has always .replace and .merge
composableDerivation {} {
...
}
svn path=/nixpkgs/trunk/; revision=14428
