The default prefix of dependabot is "build(deps)". Change it to "CI".
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Fix the following error:
```
The following packages have unmet dependencies:
binutils : Conflicts: binutils:i386 but 2.38-4ubuntu2.4 is to be installed
binutils:i386 : Conflicts: binutils but 2.38-4ubuntu2.3 is to be installed
binutils-common : Breaks: binutils-common:i386 (!= 2.38-4ubuntu2.3) but 2.38-4ubuntu2.4 is to be installed
binutils-common:i386 : Breaks: binutils-common (!= 2.38-4ubuntu2.4) but 2.38-4ubuntu2.3 is to be installed
libbinutils : Breaks: libbinutils:i386 (!= 2.38-4ubuntu2.3) but 2.38-4ubuntu2.4 is to be installed
libbinutils:i386 : Breaks: libbinutils (!= 2.38-4ubuntu2.4) but 2.38-4ubuntu2.3 is to be installed
libctf0 : Breaks: libctf0:i386 (!= 2.38-4ubuntu2.3) but 2.38-4ubuntu2.4 is to be installed
libctf0:i386 : Breaks: libctf0 (!= 2.38-4ubuntu2.4) but 2.38-4ubuntu2.3 is to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
```
Run `apt-get upgrade` before installing additional packages.
Signed-off-by: K.Takata <kentkt@csc.jp>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim does not detect pacman.log file
Solution: Detect pacmanlogs and add syntax highlighting
pacman.log is a filetype common to Arch Liux and related distributions.
Add some simple syntax highlighting for the pacmanlog filetype.
closes: #13618
Signed-off-by: Ronan Pigott <ronan@rjp.ie>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Sometimes patches add files that should be included in tarballs for
distribution, but are not added to Filelist (used by Makefile to build
the tar archive). This can break the build, or it can be silently
ignored as runtime files are simply not included in the distribution.
Add a CI check to ensure all files tracked in the repository are
assigned to a variable in Filelist. A few files were not listed because
they do not need to be included in builds and tarballs, so add an IGNORE
variable for these exceptions.
Co-authored-by: Peter Simonyi <pts@petersimonyi.ca>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Add syntax and filetype plugins for SWIG (Simplified Wrapper Interface
Generator) description files.
The default syntax for .i files highlights comments in a reverse
color scheme which doesn't look well. This syntax builds
on vim's c++ syntax by adding highlighting for common swig
directives and user defined directives. For an alternative
syntax, see vimscript #1247 (which I found after writing this).
closes: #13562
Co-authored-by: Matěj Cepl <mcepl@cepl.eu>
Co-authored-by: Julien Marrec <julien.marrec@gmail.com>
Signed-off-by: Julien Marrec <julien.marrec@gmail.com>
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: No filetype support for xcompose files
Solution: Add filetype detection
closes: #13508
Signed-off-by: ObserverOfTime <chronobserver@disroot.org>
Signed-off-by: Christian Brabandt <cb@256bit.org>
In CI, turn on warnings as errors, but ignore deprecated warnings as we
are still using NSConnection right now and we won't be fixing that for
now. Don't turn on warnings as errors for development (similar to Vim
itself) / outside of CI, because it could make it annoying to build
MacVim locally and across different Xcode versions.
Fix the misc warnings. A lot of 64/32-bit warnings due to careless casts
of NSInteger/NSUInteger.
Also fix up MacVimTests so the waiting for Vim window is more robust
when waiting for 2 windows in a row in vim tutor. Otherwise sometimes
the tests would randomly fail in CI.
* Update Debian runtime files
Add mantic as a supported Ubuntu release and move buster/kinetic to
unsupported.
Add syntax highlighting for deb822sources filetype.
Add debsources ftplugin to set relevant comment options.
Move common version information to shared/debversions.vim
Closes#11934
Co-authored-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Co-authored-by: James Addison <jay@jp-hosting.net>
Co-authored-by: Viktor Szépe <viktor@szepe.net>
Signed-off-by: James McCoy <jamessan@jamessan.com>
* Add myself as codeowner for Debian-related runtime files
Signed-off-by: James McCoy <jamessan@jamessan.com>
---------
Signed-off-by: James McCoy <jamessan@jamessan.com>
Co-authored-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Co-authored-by: James Addison <jay@jp-hosting.net>
Co-authored-by: Viktor Szépe <viktor@szepe.net>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Add a few tests for MacVim using XCTest. Previously MacVim had
essentially zero automatic tests. While we run the Vim tests in CI,
those mostly exercise Vim features, not MacVim. These new tests are
Objective C tests that are designed for MacVim-layer functionality
instead. Only adding a few tests (both unit tests and integration tests)
now to get started and set up a template for different types of tests
but more will be added later.
Since MacVim consists of a lot of macOS API calls, a lot of those
functionality are not easy to test automatically as they rely on
behaviors out of MacVim's control (e.g. full screen functionality). The
goal here is not to get 100% test coverage, but to catch areas prone to
have regressions, code with non-straightforward logic, functionality
that are annoying to manually test (e.g. key input), code blocks that
perform calculations and can be easily unit tested. Areas that would be
harder to add tests for include integration with macOS, e.g. full screen
or dual monitor, interacting with the windowing system, or things that
require screenshots in order to properly validate.
The goal here is to progressively add more tests as we touch different
parts of MacVim to help catch regressions. Old code that works and isn't
being touched will be lower priority as it's unlikely they will suddenly
break.
Certain newer Xcode features such as parallel builds require a newer
version to be specified in the project file. Currently, even though we
have enabled `BuildIndependentTargetsInParallel` in the project file,
because the objectVersion is still set at 47 (Xcode 6.3), the setting is
not used and we get a warning during build time. Upgrade the version to
54 (as automatically done by Xcode) which is Xcode 12 compatible in
order to take advantage of parallle builds.
One caveat of incrementing the version is that older Xcode versions will
not be able to open the project anymore (despite them being able to
build it in command-line using xcodebuild). Generate a new xcodeproj
with the old objectVersion and have CI check that it's not out of date
whenever we change the original xcodeproj, so people using older Xcode
versions can still debug and use Xcode with MacVim.
Note that the compatible version is compatible with Xcode 6.4, but the
xib files are only buildable in Xcode 8+, so we just call it
MacVim_xcode8.xcodeproj.
Related: #1100
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.
They do no longer support us, since they are shifting away to AI/ML
projects only. So remove any mentioned of using huntr.dev
https://huntr.com/new-huntr-faq/
Signed-off-by: Christian Brabandt <cb@256bit.org>
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.
Problem: No support for writing extended attributes
Solution: Add extended attribute support for linux
It's been a long standing issue, that if you write a file with extended
attributes and backupcopy is set to no, the file will loose the extended
attributes.
So this patch adds support for retrieving the extended attributes and
copying it to the new file. It currently only works on linux, mainly
because I don't know the different APIs for other systems (BSD, MacOSX and
Solaris). On linux, this should be supported since Kernel 2.4 or
something, so this should be pretty safe to use now.
Enable the extended attribute support with normal builds.
I also added it explicitly to the :version output as well as make it
able to check using `:echo has("xattr")`, to have users easily check
that this is available.
In contrast to the similar support for SELINUX and SMACK support (which
also internally uses extended attributes), I have made this a FEAT_XATTR
define, instead of the similar HAVE_XATTR.
Add a test and change CI to include relevant packages so that CI can
test that extended attributes are correctly written.
closes: #306closes: #13203
Signed-off-by: Christian Brabandt <cb@256bit.org>
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>
