Switch back to Ubuntu 18.04 for buliding the appimage. This allows for
using the appimage on older systems that do not provide GLIBC_2.29.
Fixes#19711.
Fixes#20113.
Our previous mangling of gettext broke the `HAVE_WORKING_LIBINTL` test
because it prevented CMake from finding `libintl.h`. Let's fix that by
linking Gettext's `include` directory into `/usr/local` too.
After some tweaks to our dep builds, we can now build a universal binary
for macOS by using `CMAKE_OSX_ARCHITECTURES`. So, let's do that. This
requires a number of additional changes:
1. We need to build on macOS 11, since earlier versions do not support
building universal (M1 + Intel) binaries.
2. We need to provision a universal `libintl`. The linker will look for
an ARM64 version of this library when linking the `nvim` binary.
While we're here:
1. Link statically to `libintl`. This allows to to avoid having to do
any install name rewriting or codesigning to package Neovim.
2. Bump the `MACOSX_DEPLOYMENT_TARGET` to `11`. We're already using a
`libintl` built by Homebrew (through the pre-installed version of
`gettext`), and that is built for macOS 11.
In order to ensure we link to `libintl.a` instead of `libintl.dylib`, we
have to make sure that CMake can't find the latter. This ideally should
be a matter of doing `brew unlink gettext`. However, CMake is too adept
at finding things that Homebrew has installed (even when not linked), so
we have to do a bit more than that. This appears in the additional step
ensuring static linkage to `libintl`.
We end up breaking some Homebrew-installed software in the process, and
some of these software is called during our build (e.g. curl, git,
wget). To avoid any adverse effects, let's just uninstall them.
Problem:
The release script bundles a system library (CoreServices) that was
added in #18294, which leads to errors on M1 since the architecture is
different from the Github runner.
Solution:
Skip CoreServices when bundling the libraries (as was done for the
CoreFoundation library that #18294 replaced with CoreServices).
- Removed NSIS installer.
- Prevents undefined behaviour when two installations are performed to the same directory (NSIS + MSI).
- Reduced cost of maintaining two installers that do the same thing.
- Chose Wix MSI due to its better integration with Windows.
- Added Wix patch file to add neovim binaries to the system path during installation.
- Replaced neovim installer icons with better looking versions.
- Renamed neovim installer icons from logo.ico -> neovim.ico for all
icons to better reflect contents.
Addresses: #12571
- Added the following installers through CMake files:
- Windows NSIS.
- Windows MSI.
- Windows zip.
- MacOs tarball.
- Linux tarball.
- Linux Deb package.
- Tweaked pipeline CPack commands to build using new CMakeLists.txt configuration file.
- Added icons and relevant packaging files.
- Updated notes.md to reflect new installation instructions.
This isn't meant to be the perfect solution, it's simply a first pass at using a
simple packaging system to build Windows installers. A Debian package has also
been added since it's very easy but other packages have been left out due to
limiting the scope. Hopefully we can build further upon this and improve it
over time with code signing, better icons and more user-friendly installation
graphics and so on.
The VS 2019 CMake generator no longer has different generator types for
different architectures. Now, the architecture is specified via CMake's
`-A` switch. However, this requires we also propagate
`${CMAKE_GENERATOR_PLATFORM}` to the bundled deps, so they build for the
same architecture as Nvim.
Even though the releaes itself gets deleted, if the tag is not, then
creating a new release just re-uses the same tag, even though we're
using “--target <sha>”.
[skip ci]
Unlike Release build type, RelWithDebInfo does not disable asserts.
This helps get better debug info from people brave enough to use the
nightly builds, but shouldn't be used for official releases.
[skip ci]
In https://github.com/neovim/neovim/issues/14150 , investigations showed
that using an older gcc to build the appimage could result in severe
perf issues. This is because older gcc versions happily replace calls to
libc functions with their own, which happen to be less optimized than
their libc counterparts.
We fix this problem by upgrading to gcc-11 on ubuntu-18.04.
This reverts #13733. Disabling delete of the release leaves behind a
draft release associated with the previous nightly tag, which is
annoying to cleanup.
In the rare circumstances that the creation of a new nightly fails after
deleting the previous nightly, the job can be re-run or a nightly can be
missing for a day.
Assuming the `CMAKE_BUILD_TYPE` directive is case-sensitive, this *actually* prevents the nightly build from being optimized. Even if it doesn't, the typo causes `:checkhealth` to issue a dummy warning in the Performance section.
