The other vim derivations all use a common definition of
`hardeningDisable` which disables `fortify`. The vim source already sets
`-D_FORTIFY_SOURCE=1` so it's not fully disabled, though it's certainly
weaker than what we get if we don't disable it.
Disabling `fortify` like this fixes a crash that occurs as a consequence
of `strictflexarrays1` now being enabled by default. Arguably we should
just disable that instead of disabling `fortify` but this keeps us
consistent with the other vim derivations.
This commit was created by a combination of scripts and tools:
- an ast-grep script to prefix things in meta with `lib.`,
- a modified nixf-diagnose / nixf combination to remove unused `with
lib;`, and
- regular nixfmt.
Co-authored-by: Wolfgang Walther <walther@technowledgy.de>
This uses the nixpkgs SDK to build, which means we can get rid of a lot
of our build hacks. This does mean we're now assuming that Xcode is in
`/Applications/Xcode.app` instead of letting xcode-select find it,
though this is configurable.
Reenable python3 support since using the nixpkgs SDK fixes the
incompatibility there.
Switch lua/perl/python/ruby/tcl support away from dynamic since vim
isn't finding the right libraries anymore, for some reason.
Remove some of the other old stuff like bits of the patchfile that don't
seem to be needed anymore.
Updates macvim to r181, including bumping the Ruby version to 3.4 since
that's what MacVim r181 is built against.
There's still 3 CVEs in the `knownVulnerabilities` list that are newer
than this release, but this is the latest MacVim release available right
now.
MacVim currently fails to link against nixpkgs python because Xcode's
clang doesn't understand the LLVM bitcode in the
`libpython${pythonVersion}.a` static library. I'm not sure what this
static library is for when `lib/libpython${pythonVersion}.dylib` exists,
but I don't know of a way to tell MacVim to ignore it. Linking against
python works if we rebuild python to skip the static library but that
doesn't seem like a proper solution, so until a permanent solution is
found, just disable python by default.
Also mark macvim as no longer broken.
Pass `-headerpad_max_install_names` again. This is something we used to
do, and then the flag got removed at some point. For some reason we need
to provide it both to configure and to Xcode.
Xcode 26.0 sets `*_DEPLOYMENT_TARGET` env vars for all platforms in
shell script build phases, which breaks invocations of clang from those
phases, as they target the wrong platform.
This was done with booxter’s fantastic [nix-clean-apple_sdk] tool,
simply modified to look for `libobjc` rather than the existing list he
already used in <https://github.com/NixOS/nixpkgs/pull/398707>. Some
manual work was applied, including cleaning up a string interpolation
in the terrifying MacVim derivation, stray comments, empty lists,
function parameters, and `inherit`s, including all of the references in
`all-packages.nix`.
[nix-clean-apple_sdk]: https://github.com/booxter/nix-clean-apple_sdk
After final improvements to the official formatter implementation,
this commit now performs the first treewide reformat of Nix files using it.
This is part of the implementation of RFC 166.
Only "inactive" files are reformatted, meaning only files that
aren't being touched by any PR with activity in the past 2 months.
This is to avoid conflicts for PRs that might soon be merged.
Later we can do a full treewide reformat to get the rest,
which should not cause as many conflicts.
A CI check has already been running for some time to ensure that new and
already-formatted files are formatted, so the files being reformatted here
should also stay formatted.
This commit was automatically created and can be verified using
nix-build a08b3a4d19.tar.gz \
--argstr baseRev 57b193d8dd
result/bin/apply-formatting $NIXPKGS_PATH
MacVim needs to use the system Xcode to build. Having `DEVELOPER_DIR`
set in the environment causes Xcode to try to use the nixpkgs SDK, which
doesn’t work. Unsetting it allows MacVim to build.
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.
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.
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.
