Currently this is only for pre-release builds as main releases usually
use hand-written release notes. However, eventually main release notes
may use this as part of the full release notes to allow people to look
at the full list of changes, but I haven't decided if that's desired
yet as it may just be duplicate information.
From testing and benchmarking, it appears that both result in a
measurable improvement in performance, wtih some benchmarks showing 10%
faster (when opening a large 400 MB binary file and
searching-and-replacing within it). Use them when building a published
build. Don't do it for legacy builds as I encountered some issues with
it failing tests when testing for recursion limit and I suspect it's due
to stack size issues. Since legacy builds are mostly kept for
compatibility reasons, no need to optimize it for now.
When Apple Silicon came out, we needed to get universal binaries of
gettext/libsodium to link against, and solved it in a somewhat hacky
temporary solution by just downloading the bottles from Homebrew and
patching them with the x86_64 version. However, Homebrew only maintains
bottles for 3 recent OSes, and with macOS 14's release, they no longer
have bottles for macOS 11, which we still want to support as it's a
recent OS. As such, we need to build the arm64 version of the packages
in CI as well instead of just downloading.
When installing from source, Homebrew uses a custom "clang" script that
injects compiler flags including "-march" which will cause clang to fail
to work when building universal binaries (since it doesn't make sense
to specify Intel architectures when specifying `-arch arm64`). Just
force it to use system clang instead to avoid inject unwanted flags.
For some reason `brew install python3` is failing in GitHub Action's
macos-13 image due to stale 2to3/etc links. Simply remove the install
step. We no longer need it as we have stable ABI now and we don't need
latest version.
Also, fix Python 2's installation link using an outdated version for
some reason.
Python2
- Python2 is no longer installed in the new GitHub hosted runners
(macos-13) and so we need to manually download the installer from
Python's website and install it. Since it seems to run quite fast, not
caching the folder fow now.
- Had to change the default Python2 dynamic lib location to
/Library/Framework/... which is where the installer installs to.
- Should warn users that Python2 support could be removed in the future.
Lua
- Previously dynamic lib loading implicitly relied on being able to find
the lib from /usr/local/lib. Somehow Xcode 15 removed support for that
folder when using dlopen(). Modified CI and configure script to allow
manually specifying it.
Xcode / Legacy build
- GitHub's macos-13 image does not have Xcode 14.0.1 installed. This is
the version we need for building legacy builds (targeting macOS 10.9 -
10.12). As such, we need to keep using macos-12 for building legacy
builds. Hopefully it won't be deprecated soon as we would need to
investigate options for how to build legacy builds.
Fix deprecated C functions using old style declarations to handle new
compiler warnings.
Problem: CI: change netrw label in labeller bot
Solution: Rename it to 'plugin-netrw'
closes: #13217
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Ken Takata <kentkt@csc.jp>
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.
