It's a leftover artifact that currently just acts as an unnecessary
intermediary script that calls the Makefile. It can be replaced by just
calling the Makefile directly.
Problem:
Dirs "config", "packaging", and "third-party" are all closely related
but this is not obvious from the layout. This adds friction for new
contributors.
Solution:
- rename config/ to cmake.config/
- rename test/config/ to test/cmakeconfig/ because it is used in Lua
tests: require('test.cmakeconfig.paths').
- rename packaging/ to cmake.packaging/
- rename third-party/ to cmake.deps/ (parallel with .deps/)
* build: move the logic for linters to cmake
Cmake is our source of truth. We should have as much of our build
process there as possible so everyone can make use of it.
* build: remove redundant check for ninja generator
The minimum cmake version as of writing this is 3.10, which has ninja
support.
> DEPRECATION: Python 2.7 reached the end of its life on January 1st, 2020
Testing `pynvim` compatibility with python2 should not be done in core,
and there's only a provider_spec for python3 either way.
On GitHub Actions it just repeats the summary that is shown just after.
When run outside of GitHub Actions it erroneously shows the summary of
the previous suites.
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.
It's only used once for running check-single-includes (which I strongly
suspect it doesn't need anyway), its core logic is incorrect since both the
variables "tempsize" and "prev_temsize" are never defined and parsing ps
is incredibly fragile.
