Commit Graph

13 Commits

Author SHA1 Message Date
dundargoc
a0292b4e5f build: remove libfindmacros library (#22423)
Large parts the library weren't being used, and the parts that were was overly
abstracted for our use case. Additionally, part of its use case was to abstract
pkgconfig boilerplate, which is no longer needed as pkgconfig has been removed
in favor of relying on cmake alone in 09118052ce.
2023-03-02 10:22:41 +01:00
dundargoc
1e37703a74 build: remove pkgconfig-related code (#22422)
Cmake should already be able to find everything on its own.
2023-02-26 22:32:08 +01:00
Dundar Goc
a4c0c07043 revert: "ci: remove mingw job #18580"
This partially reverts commit f8af81445b.

The mingw parts of cmake was removed to see if it was still used
(ref: https://github.com/neovim/neovim/pull/18580). It turns out it is,
so this will fix that.

Closes: https://github.com/neovim/neovim/issues/18597
2022-05-17 17:07:45 +02:00
dundargoc
f8af81445b ci: remove mingw job #18580
Unnecessary CI builds increase the change of spurious failures, which are costly
noise. Of course, we should fix all legitimate bugs, but we also cannot
micro-manage every platform, so there needs to be a clear motivation for the CI
builds that we maintain.

Reasons against maintaining a mingw CI job:
1. The windows mingw build is slow.
2. Failures:
    - https://github.com/neovim/neovim/issues/18494
    - https://github.com/neovim/neovim/issues/18495
3. The mingw artifact is 10x bigger than the windows MSVC artifact:
   https://github.com/neovim/neovim/issues/10560
4. Our releases publish the MSVC (not mingw) artifact for Windows users:
   https://github.com/neovim/neovim/releases
5. Non-MSVCRT has limitations documented by libuv: http://docs.libuv.org/en/v1.x/process.html
   > On Windows file descriptors greater than 2 are available to the child process only if the child processes uses the MSVCRT runtime.

Closes https://github.com/neovim/neovim/issues/18551
2022-05-15 15:59:58 -07:00
Daniel Hahler
6ebe476675 build: clean up / remove X_USE_STATIC (#10713)
This was discouraged (as an option) in 5b5d353151 [1], not enabled/used by
default, and not working according to the comment in local.mk.example.

Taken out of https://github.com/neovim/neovim/pull/10395.

1: https://github.com/neovim/neovim/pull/2465
2019-08-07 22:19:55 +02:00
Daniel Hahler
f668f0afb2 build: FindLuaJit: handle luajit-2.1 include path suffix (#10418) 2019-07-04 15:19:25 +02:00
Daniel Hahler
6765bbc651 build: CMake: remove usage of USE_BUNDLED_X in main project (#10354)
The variables are not meant to be defined there really, but only with
the third-party project.

Using them, e.g. with the following, would actually result in libvterm
not being found then:

    make CMAKE_EXTRA_FLAGS="-DUSE_BUNDLED_LIBVTERM=ON" \
      DEPS_CMAKE_FLAGS="-DUSE_BUNDLED=OFF -DUSE_BUNDLED_LIBVTERM=ON"

In https://github.com/neovim/neovim/pull/6357 they were renamed to
`USE_BUNDLED_X` from `X_USE_BUNDLED`, but the above reasoning applies
to the old names, too.

Internally `CMAKE_PREFIX_PATH` is used to add the built/bundled third
party packages for `find_package`, so there is no reason to e.g. query
the values via `load_cache` for example from the third-party project.
2019-06-28 02:02:19 +02:00
Daniel Hahler
b60e5c85ad cmake: USE_BUNDLED_X instead of X_USE_BUNDLED (#6357) 2017-03-25 23:02:20 +01:00
Rui Abreu Ferreira
655f1b7513 MinGW: Add libluajit-5.1 lib name to FindLuaJit 2015-12-02 23:07:22 -05:00
Rui Abreu Ferreira
d00d37b486 Windows: FindLuaJit: fix libname. #3262 2015-08-31 03:16:35 -04:00
Florian Walch
2446b997c6 CMake: Remove duplicate PkgConfig lookups. 2015-04-29 22:26:55 +03:00
John Szakmeister
279c519e33 build: fix a typo in a comment of FindLuaJit.cmake 2014-12-02 18:44:15 -05:00
John Szakmeister
0b2f6a0cf4 Revamp the build system.
This achieves several goals:

 * Less reliance on scripts so we have better portability to Windows
   (though we still have a ways to go for proper Windows support).
   Luajit, luarocks, moonscript, and busted are all installed via CMake
   now.
 * Trying to make use of pkg-config to get the correct libraries.  The
   latest libuv is still broken in this regard, but we'll at least be in
   a position to use it.
 * Allow the use of Ninja or make.  The former runs faster in many
   environments, and automatically makes use of parallel builds.

This also allows for system installed dependencies--though not through
the Makefile just yet--and adds support for FreeBSD.

This also make us build libuv and luajit as static libraries only, since
we're only concerned about having static libraries for our bundled
dependencies.
2014-03-21 15:22:00 -04:00