about summary refs log tree commit diff
path: root/pkgs/applications/editors/vim/macvim.nix
AgeCommit message (Collapse)AuthorFilesLines
2023-10-04treewide: remove cstrahan from meta.maintainers - part 2Anderson Torres1-1/+1
19 files modified with this removal
2023-01-16macvim: use python3 instead of python37Nick Cao1-4/+4
2022-12-05macvim: remove python2 optionTheodore Ni1-16/+17
2022-02-12macvim: 8.2.1719 -> 8.2.3455Brian Leung1-3/+3
2021-01-19treewide: pkgs.pkgconfig -> pkgs.pkg-config, move pkgconfig to alias.nixJonathan Ringer1-2/+2
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.
2021-01-11treewide: with stdenv.lib; in meta -> with lib;Profpatsch1-2/+2
Part of: https://github.com/NixOS/nixpkgs/issues/108938 meta = with stdenv.lib; is a widely used pattern. We want to slowly remove the `stdenv.lib` indirection and encourage people to use `lib` directly. Thus let’s start with the meta field. This used a rewriting script to mostly automatically replace all occurances of this pattern, and add the `lib` argument to the package header if it doesn’t exist yet. The script in its current form is available at https://cs.tvl.fyi/depot@2f807d7f141068d2d60676a89213eaa5353ca6e0/-/blob/users/Profpatsch/nixpkgs-rewriter/default.nix
2020-11-05macvim: fix building with nix-daemon (#102975)Lily Ballard1-0/+13
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.
2020-09-28macvim: 8.2.539 -> 8.2.1719Lily Ballard1-3/+3
2020-09-28macvim: Properly link against Nix ncursesLily Ballard1-3/+4
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.
2020-04-28macvim: Clean up hybrid compilation environmentLily Ballard1-17/+27
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.
2020-04-15macvim: 8.2.319 -> 8.2.539Lily Ballard1-3/+3
2020-04-15macvim: Fix compatibility with Xcode 11.4Lily Ballard1-0/+10
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`.
2020-04-10treewide: Per RFC45, remove all unquoted URLsMichael Reilly1-1/+1
2020-03-03macvim: 8.1.2234 -> 8.2.319Lily Ballard1-15/+13
2019-11-17macvim: Add -headerpad_max_install_names (#73592)Lily Ballard1-0/+1
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
2019-11-07macvim: snapshot-157 -> snapshot-161Lily Ballard1-6/+4
2019-10-09Merge pull request #69576 from lilyball/macvim-no-chrootworldofpeace1-0/+9
macvim: Add sandboxProfile
2019-09-27macvim: Add sandboxProfileLily Ballard1-0/+9
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.
2019-09-26Merge pull request #68534 from lilyball/macvim-xcode-11-fixJörg Thalheim1-0/+3
macvim: fix compatibility with Xcode 11
2019-09-11macvim: fix compatibility with Xcode 11Lily Ballard1-0/+3
This fixes several Xcode 11 incompatibilities with MacVim, including an issue where it wasn't inheriting the deployment target correctly to begin with.
2019-09-11macvim: work around ibtool issueLily Ballard1-1/+5
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.
2019-08-28treewide: remove redundant recvolth1-1/+1
2019-08-17Merge staging-next into stagingFrederik Rietdijk1-3/+3
2019-08-15treewide: name -> pname (easy cases) (#66585)volth1-1/+1
treewide replacement of stdenv.mkDerivation rec { name = "*-${version}"; version = "*"; to pname
2019-08-01macvim: 8.1.1517 -> 8.1.1722Lily Ballard1-3/+3
2019-06-11macvim: 7.4.909 -> 8.1.1517Lily Ballard1-30/+56
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.
2018-07-21pkgs/*: remove unreferenced function argumentsvolth1-1/+1
2018-02-14ruby: remove unsupported versions (#34927)zimbatm1-0/+1
* 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
2017-09-21treewide: Manual fix more pkg-config build-inputsJohn Ericson1-1/+2
2017-08-07replace "Mac OS X" and "OS X" with "macOS"davidak1-1/+1
as it is the official name since 2016 https://en.wikipedia.org/wiki/Macintosh_operating_systems#Desktop exception are parts refering to older versions of macOS like "GUI support for Mac OS X 10.6 - 10.12. Note that Emacs 23 and later [...]"
2016-05-06macvim: fix buildCharles Strahan1-0/+5
2016-03-10macvim: remove extra MacVim.appAllan Espinosa1-0/+1
/MacVim.app is a duplicate of /Applications/MacVim.app
2015-11-15macvim: 7.4.648 -> 7.4.909 (and fix build)Charles Strahan1-6/+17
2015-08-04macvim: fix bad copy/paste in 6f08fdd26Charles Strahan1-1/+1
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.
2015-08-04macvim: 7.4.479 -> 7.4.648Charles Strahan1-4/+4
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).
2015-05-28Don't use "with licenses;" for single licencesTobias Geerinckx-Rice1-1/+1
And don't use square brackets on such lines.
2015-05-27vim (all builds): add licence informationTobias Geerinckx-Rice1-0/+1
2014-11-03macvim: Update sha256John Wiegley1-1/+1
2014-11-03Use fetchurl and the exact release tagAllan Espinosa1-5/+3
2014-11-03Update the sha256sum of the new MacVim buildAllan Espinosa1-1/+1
Correct the update from #4576
2014-10-18Fix MacVim by using clang.Charles Strahan1-5/+7
2014-07-14Merge remote-tracking branch 'origin/master' into stagingEelco Dolstra1-4/+4
2014-07-07Update `macvim` package to v7.4.355Charles Strahan1-4/+4
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.
2014-06-30Another attempt to eradicate ensureDirEelco Dolstra1-1/+1
See c556a6ea46e71e1907d78b71fab36df30297b3ad.
2014-06-07macvim: add missing call to ensureDirJohn Wiegley1-0/+1
2014-06-07macvim: move the .app bundle to $out/ApplicationsJohn Wiegley1-3/+3
2014-06-07add MacVimCharles Strahan1-0/+92