Previously, MacVim's build process simply used an Xcode post-build
script to copy the runtime folder to the target app bundle's
Contents/Resources/vim/runtime folder and called it a day. However,
that's actually not the correct procedure because the runtime folder
contains misc files (e.g. Makefile/testdir for testing) and they should
go through a install step using `make install` to properly deploy the
proper files to the target folder.
Fix this by changing the post-build script to call the relevant make
targets instead of just blindly copying it over. We still copy the
vim/view/etc and vimtutor binaries separately for now, because the mvim
script is a custom script for MacVim, although that could change in
future.
One of the corollary of using the builtin installation scripts is that
man pages (for CLI vim/gvim usage) are now properly generated. They are
now stored under `MacVim.app/Contents/man`, and a user can set MANPATH to
it if they so wish.
Another corollary is that we now bundle xxd with MacVim like most Vim
distributions. It was probably an oversight before, and now it's built
and bundled in the `MacVim.app/Contents/bin` folder like the
vim/view/mvim scripts.
One annoying thing with Xcode is that in order for incremental builds to
work properly we want it to only run this installation step if the
runtime folder has changed (it takes a couple secs to finish) and
Xcode's input file lists doesn't support recursive folder search. To fix
this, add a build step to manually generate the list of all runtime
folders called runtime_folder_list.xcfilelist which we pass to the build
step.
Fix#1417
Vim added support for using Python 3 stable ABI in 9.0.1776, which
allows us to safely load Python libraries of a different version from
what Vim was built against. Modify our CI to use that. This allows user
to use whatever Python version they want as long as it's above the
minimum target. Given that macOS/Xcode still ships with 3.9 by default,
we build using 3.9 as the minimum version.
Also, change our Python detection script to work better. Change all
explicit versions in our paths to refer to the "Current" version instead
which for the most part should "just work" instead of requiring an exact
match every time we or Python update to a new version (e.g. Homebrew
will update the Current version to point to the latest Python3). Also
add support for finding Python 3 from Xcode Command Line Tools which was
previously not ok to use technically because it's 3.9 and before stable
ABI support we couldn't load it safely as MacVim was built using newer
versions.
Fix#1351.
Previously, Vim didn't always have up-to-date help tags. As a result, we
just manually generate the help tags when publishing a release (#1286),
even though it doesn't actually make sure the tags file in source is
actually accurate. However, Vim has since added CI checks to make sure
the help tags are correct, so we can change MacVim CI to do the same
thing as well. This way, the source version is always correct and we
won't rely on a build step during release to fix it, and it also makes
sure other methods to get MacVim (build from source, Homebrew) will be
correct as well.
Problem: Github CI does not run i386 job
Solution: Add a i386 architecture
Add CI testing for i386
message_test recently failed on i386, which exposed a gap in the CI
testing. Convert the shadowdir job to one that runs on i386 so we get
32-bit test coverage.
Since the GHA runners are x86_64, we can enable the i386 architecture
in dpkg and install i386 packages for the i386 CI jobs. However, this
can't currently be done with features=huge since that would require
installing python3-dev:i386, which breaks the CI environment.
closes: #12975
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: James McCoy <jamessan@jamessan.com>
Problem: doc helptags may not be up to date
Solution: Add CI jobs to verify helptags are updated
Also, re-generate the tags file with updated list so it will pass CI.
closes: #13012
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Github CI too complex
Solution: CI: Tidy up matrix
Perform the following changes to the CI configuration:
- Move common CFLAGS to ci/config.mk.sed
- Change extra key to array to able to assign no or multiple values
explicitly
- Modify luaver variable handling
- lib${{ matrix.luaver }}-dev ${{ matrix.luaver }} are confusing
as package names
- Deduplicate CONFOPT setting
closes: #12955
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: ichizok <gclient.gaap@gmail.com>
Problem: No tests for the termdebug plugin
Solution: Add some simple tests for the termdebug plugin
closes: #12927
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem: No support for stable Python 3 ABI
Solution: Support Python 3 stable ABI
Commits:
1) Support Python 3 stable ABI to allow mixed version interoperatbility
Vim currently supports embedding Python for use with plugins, and the
"dynamic" linking option allows the user to specify a locally installed
version of Python by setting `pythonthreedll`. However, one caveat is
that the Python 3 libs are not binary compatible across minor versions,
and mixing versions can potentially be dangerous (e.g. let's say Vim was
linked against the Python 3.10 SDK, but the user sets `pythonthreedll`
to a 3.11 lib). Usually, nothing bad happens, but in theory this could
lead to crashes, memory corruption, and other unpredictable behaviors.
It's also difficult for the user to tell something is wrong because Vim
has no way of reporting what Python 3 version Vim was linked with.
For Vim installed via a package manager, this usually isn't an issue
because all the dependencies would already be figured out. For prebuilt
Vim binaries like MacVim (my motivation for working on this), AppImage,
and Win32 installer this could potentially be an issue as usually a
single binary is distributed. This is more tricky when a new Python
version is released, as there's a chicken-and-egg issue with deciding
what Python version to build against and hard to keep in sync when a new
Python version just drops and we have a mix of users of different Python
versions, and a user just blindly upgrading to a new Python could lead to
bad interactions with Vim.
Python 3 does have a solution for this problem: stable ABI / limited API
(see https://docs.python.org/3/c-api/stable.html). The C SDK limits the
API to a set of functions that are promised to be stable across
versions. This pull request adds an ifdef config that allows us to turn
it on when building Vim. Vim binaries built with this option should be
safe to freely link with any Python 3 libraies without having the
constraint of having to use the same minor version.
Note: Python 2 has no such concept and this doesn't change how Python 2
integration works (not that there is going to be a new version of Python
2 that would cause compatibility issues in the future anyway).
---
Technical details:
======
The stable ABI can be accessed when we compile with the Python 3 limited
API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c`
and `if_py_both.h`) would now handle this and switch to limited API
mode. Without it set, Vim will still use the full API as before so this
is an opt-in change.
The main difference is that `PyType_Object` is now an opaque struct that
we can't directly create "static types" out of, and we have to create
type objects as "heap types" instead. This is because the struct is not
stable and changes from version to version (e.g. 3.8 added a
`tp_vectorcall` field to it). I had to change all the types to be
allocated on the heap instead with just a pointer to them.
Other functions are also simply missing in limited API, or they are
introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that
we need some other ways to do the same thing, so I had to abstract a few
things into macros, and sometimes re-implement functions like
`PyObject_NEW`.
One caveat is that in limited API, `OutputType` (used for replacing
`sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't
think has any real issue other than minor differences in how they
convert to a string and missing a couple functions like `mode()` and
`fileno()`.
Also fixed an existing bug where `tp_basicsize` was set incorrectly for
`BufferObject`, `TabListObject, `WinListObject`.
Technically, there could be a small performance drop, there is a little
more indirection with accessing type objects, and some APIs like
`PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any
difference, and any well-written Python plugin should try to avoid
excessing callbacks to the `vim` module in Python anyway.
I only tested limited API mode down to Python 3.7, which seemes to
compile and work fine. I haven't tried earlier Python versions.
2) Fix PyIter_Check on older Python vers / type##Ptr unused warning
For PyIter_Check, older versions exposed them as either macros (used in
full API), or a function (for use in limited API). A previous change
exposed PyIter_Check to the dynamic build because Python just moved it
to function-only in 3.10 anyway. Because of that, just make sure we
always grab the function in dynamic builds in earlier versions since
that's what Python eventually did anyway.
3) Move Py_LIMITED_API define to configure script
Can now use --with-python-stable-abi flag to customize what stable ABI
version to target. Can also use an env var to do so as well.
4) Show +python/dyn-stable in :version, and allow has() feature query
Not sure if the "/dyn-stable" suffix would break things, or whether we
should do it another way. Or just don't show it in version and rely on
has() feature checking.
5) Documentation first draft. Still need to implement v:python3_version
6) Fix PyIter_Check build breaks when compiling against Python 3.8
7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows
This adds configurable options for Windows make files (both MinGW and
MSVC). CI will also now exercise both traditional full API and stable
ABI for Linux and Windows in the matrix for coverage.
Also added a "dynamic" option to Linux matrix as a drive-by change to
make other scripting languages like Ruby / Perl testable under both
static and dynamic builds.
8) Fix inaccuracy in Windows docs
Python's own docs are confusing but you don't actually want to use
`python3.dll` for the dynamic linkage.
9) Add generated autoconf file
10) Add v:python3_version support
This variable indicates the version of Python3 that Vim was built
against (PY_VERSION_HEX), and will be useful to check whether the Python
library you are loading in dynamically actually fits it. When built with
stable ABI, it will be the limited ABI version instead
(`Py_LIMITED_API`), which indicates the minimum version of Python 3 the
user should have, rather than the exact match. When stable ABI is used,
we won't be exposing PY_VERSION_HEX in this var because it just doesn't
seem necessary to do so (the whole point of stable ABI is the promise
that it will work across versions), and I don't want to confuse the user
with too many variables.
Also, cleaned up some documentation, and added help tags.
11) Fix Python 3.7 compat issues
Fix a couple issues when using limited API < 3.8
- Crash on exit: In Python 3.7, if a heap-allocated type is destroyed
before all instances are, it would cause a crash later. This happens
when we destroyed `OptionsType` before calling `Py_Finalize` when
using the limited API. To make it worse, later versions changed the
semantics and now each instance has a strong reference to its own type
and the recommendation has changed to have each instance de-ref its
own type and have its type in GC traversal. To avoid dealing with
these cross-version variations, we just don't free the heap type. They
are static types in non-limited-API anyway and are designed to last
through the entirety of the app, and we also don't restart the Python
runtime and therefore do not need it to have absolutely 0 leaks.
See:
- https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api
- https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api
- PyIter_Check: This function is not provided in limited APIs older than
3.8. Previously I was trying to mock it out using manual
PyType_GetSlot() but it was brittle and also does not actually work
properly for static types (it will generate a Python error). Just
return false. It does mean using limited API < 3.8 is not recommended
as you lose the functionality to handle iterators, but from playing
with plugins I couldn't find it to be an issue.
- Fix loading of PyIter_Check so it will be done when limited API < 3.8.
Otherwise loading a 3.7 Python lib will fail even if limited API was
specified to use it.
12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API
We don't use this function unless limited API >= 3.10, but we were
loading it regardless. Usually it's ok in Unix-like systems where Python
just has a single lib that we load from, but in Windows where there is a
separate python3.dll this would not work as the symbol would not have
been exposed in this more limited DLL file. This makes it much clearer
under what condition is this function needed.
closes: #12032
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
Problem: Runtime: Missing QML support
Solution: Add QML support to Vim
closes: #12810
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: ChaseKnowlden <haroldknowlden@gmail.com>
Problem: CI: label should not be set on all yml files
Solution: only set it for specific yml files in .github
closes: #12855
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Philip H <47042125+pheiduck@users.noreply.github.com>
Problem: Github CI fails to load snd-dummy kernel module
Solution: Make installation of linux-modules-extra optional
linux-modules-extra package are not available on Ubuntu 22 at the
moment, which breaks CI runs. The change make its installation
conditional as the original `if-else` structure tried to do.
closes: #12801
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Zdenek Dohnal <zdohnal@redhat.com>
This is a collection of various PRs from github that all require a minor
patch number:
1) https://github.com/vim/vim/pull/12612
Do not conflate dictionary key with end of block
2) https://github.com/vim/vim/pull/12729:
When saving and restoring 'undolevels', the constructs `&undolevels` and
`:set undolevels` are problematic.
The construct `&undolevels` reads an unpredictable value; it will be the
local option value (if one has been set), or the global option value
(otherwise), making it unsuitable for saving a value for later
restoration.
Similarly, if a local option value has been set for 'undolevels',
temporarily modifying the option via `:set undolevels` changes the local
value as well as the global value, requiring extra work to restore both
values.
Saving and restoring the option value in one step via the construct
`:let &undolevels = &undolevels` appears to make no changes to the
'undolevels' option, but if a local option has been set to a different
value than the global option, it has the unintended effect of changing
the global 'undolevels' value to the local value.
Update the documentation to explain these issues and recommend explicit
use of global and local option values when saving and restoring. Update
some unit tests to use `g:undolevels`.
3) https://github.com/vim/vim/pull/12702:
Problem: Pip requirements files are not recognized.
Solution: Add a pattern to match pip requirements files.
4) https://github.com/vim/vim/pull/12688:
Add indent file and tests for ABB Rapid
5) https://github.com/vim/vim/pull/12668:
Use Lua 5.1 numeric escapes in tests and add to CI
Only Lua 5.2+ and LuaJIT understand hexadecimal escapes in strings. Lua
5.1 only supports decimal escapes:
> A character in a string can also be specified by its numerical value
> using the escape sequence \ddd, where ddd is a sequence of up to three
> decimal digits. (Note that if a numerical escape is to be followed by a
> digit, it must be expressed using exactly three digits.) Strings in Lua
> can contain any 8-bit value, including embedded zeros, which can be
> specified as '\0'.
To make sure this works with Lua 5.4 and Lua 5.1 change the Vim CI to
run with Lua 5.1 as well as Lua 5.4
6) https://github.com/vim/vim/pull/12631:
Add hurl filetype detection
7) https://github.com/vim/vim/pull/12573:
Problem: Files for haskell persistent library are not recognized
Solution: Add pattern persistentmodels for haskell persistent library
closes: #12612closes: #12729closes: #12702closes: #12688closes: #12668closes: #12631closes: #12573
Co-authored-by: lacygoill <lacygoill@lacygoill.me>
Co-authored-by: Michael Henry <drmikehenry@drmikehenry.com>
Co-authored-by: ObserverOfTime <chronobserver@disroot.org>
Co-authored-by: KnoP-01 <knosowski@graeffrobotics.de>
Co-authored-by: James McCoy <jamessan@jamessan.com>
Co-authored-by: Jacob Pfeifer <jacob@pfeifer.dev>
Co-authored-by: Borys Lykah <lykahb@fastmail.com>
Also, refactor CI configs to only specify the Python 3 and Perl versions
in one place, so we don't have to multiple lines in the config file.
Additionally, add checks to make sure the Homebrew Python 3 version
matches the configured one, so we will have a failed build and be
notified this way instead of silently building against an old version of
Python in CI, which would still work as GitHub CI has older versions of
Python installed.
Note that if https://github.com/vim/vim/pull/12032 is merged, this will
be less painful in the future as stable ABI should mean we don't have to
care as much about the exact Python version.
Recent Vim builds introduced the use of clock_gettime(), which on macOS
was only introduced in 10.12. In Vim, we added a configure check to
detect its existence (https://github.com/vim/vim/issues/12242) but it
only works to detect the build-time environment. For MacVim builds we
build on new machines but deploy on old machines by using
MACOSX_DEPLOYMENT_TARGET=10.9 when building. This means that the
configure script will detect clock_gettime() exists and includes it, but
at runtime the app will crash when running MacVim (legacy builds) in
10.9-10.11.
To fix this, add explicit checks to make sure we undef
HAVE_CLOCK_GETTIME if deployment target is below 10.12. Unfortunately
there isn't really a way to detect such things automatically in a
configure script as it requires knowledge of historical releases.
Use newer formats for creating the DMG file for distributing MacVim.
APFS has been supported fully since macOS 10.13, and from testing it
extracts faster than HFS+.
LZFSE (ULFO format) is newer than zlib/DEFLATE (UDZO format) and also
decompresses faster as well from testing. Note that there is a newer
compression scheme using LZMA (ULMO format) but it is only supported in
10.15+ which is too high for us as non-legacy builds need to target
10.13+. Also, from testing, the newer LZMA yields smaller files, but
takes more time to decompress than LZFSE.
Also, keeping using the old formats (HFS+/zlib) for legacy builds since
they need to work on 10.9, which don't support the newer formats.
Problem: CI: check in sound-dummy module may throw an error.
Solution: Check whether apt-cache can show the package description.
(Christian Brabandt, closes#12390)
In the CI setup, xcode-select is only called after the packages have
been set up, but during setup we actually need to build the packages
from source to have the correct deployment target linked correctly. This
means we could potentially be building with the wrong configuration
(e.g. when building for 10.9 legacy builds, we could be using an Xcode
version that's too new for that) when building gettext/libsodium. This
is compounded by the fact that our GitHub Action cache key for the
libraries only include the formula, but not the active Xcode version
itself so a cache could be propagated for a while until suddenly things
break.
To fix this, first make sure we do Xcode configuration early on in the
build, and to properly use the Xcode version as part of the cache key.
This way, when Xcode version changes, we will invalidate the cache and
rebuild gettext / libsodium with the correct configuration and if that's
wrong we will immediately fail the build instead of using old stale
caches.
Also, bump Xcode from 14.1 to 14.2 in CI.
