This file wasn't used since e1cc0fe996. That may have been
accidental, but it's not needed anymore anyway. Also the "Workaround
for hanging" is no longer relevant.
ref #9280
Introduce the `vim.compat` module, to help environments with system Lua
5.2+ run the build/tests. Include the module implicitly in all tests.
ref #8677
legacy `vim` module:
beep
buffer
command
dict
eval
firstline
lastline
line
list
open
type
window
If check_c_source_compiles() succeeded (HAVE_WORKING_LIBINTL is set)
then the result of find_xxx() doesn't matter. This happens on systems
(linux+glibc) where libintl is available passively.
This allows `find_package(LibIntl REQUIRED)` to work and will still
correctly fail (REQUIRED) on systems lacking libintl.
This helps to figure out what the problem is, e.g. in my case I have
lua51-mpack installed to be used with luajit, but it is broken (missing
libmpack).
With this patch you get:
-- Checking Lua interpreter /usr/bin/luajit
/usr/bin/luajit: error loading module 'mpack' from file '/usr/lib/lua/5.1/mpack.so':
libmpack.so.0: cannot open shared object file: No such file or directory
stack traceback:
[C]: at 0x55fcf0166fb0
[C]: in function 'require'
(command line):1: in main chunk
[C]: at 0x55fcf01188a0
-- [/usr/bin/luajit] The 'mpack' lua package is required for building Neovim
-- Checking Lua interpreter /usr/bin/lua5.1
/usr/bin/lua5.1: error loading module 'mpack' from file '/usr/lib/lua/5.1/mpack.so':
libmpack.so.0: cannot open shared object file: No such file or directory
stack traceback:
[C]: ?
[C]: in function 'require'
(command line):1: in main chunk
[C]: ?
-- [/usr/bin/lua5.1] The 'mpack' lua package is required for building Neovim
-- Checking Lua interpreter /usr/bin/lua5.2
/usr/bin/lua5.2: (command line):1: module 'mpack' not found:
no field package.preload['mpack']
no file '/usr/share/lua/5.2/mpack.lua'
no file '/usr/share/lua/5.2/mpack/init.lua'
no file '/usr/lib/lua/5.2/mpack.lua'
no file '/usr/lib/lua/5.2/mpack/init.lua'
no file './mpack.lua'
no file '/usr/lib/lua/5.2/mpack.so'
no file '/usr/lib/lua/5.2/loadall.so'
no file './mpack.so'
stack traceback:
[C]: in function 'require'
(command line):1: in main chunk
[C]: in ?
-- [/usr/bin/lua5.2] The 'mpack' lua package is required for building Neovim
-- Checking Lua interpreter /usr/bin/lua
/usr/bin/lua: (command line):1: module 'mpack' not found:
no field package.preload['mpack']
no file '/usr/share/lua/5.3/mpack.lua'
no file '/usr/share/lua/5.3/mpack/init.lua'
no file '/usr/lib/lua/5.3/mpack.lua'
no file '/usr/lib/lua/5.3/mpack/init.lua'
no file './mpack.lua'
no file './mpack/init.lua'
no file '/usr/lib/lua/5.3/mpack.so'
no file '/usr/lib/lua/5.3/loadall.so'
no file './mpack.so'
stack traceback:
[C]: in function 'require'
(command line):1: in main chunk
[C]: in ?
-- [/usr/bin/lua] The 'mpack' lua package is required for building Neovim
CMake Error at CMakeLists.txt:459 (message):
A suitable Lua interpreter was not found.
While this makes it more verbose for the expected error case ("module
'mpack' not found"), the behavior before this patch hides too much.
This is the old output:
-- Checking Lua interpreter /usr/bin/luajit
-- [/usr/bin/luajit] The 'mpack' lua package is required for building Neovim
-- Checking Lua interpreter /usr/bin/lua5.1
-- [/usr/bin/lua5.1] The 'mpack' lua package is required for building Neovim
-- Checking Lua interpreter /usr/bin/lua5.2
-- [/usr/bin/lua5.2] The 'mpack' lua package is required for building Neovim
-- Checking Lua interpreter /usr/bin/lua
-- [/usr/bin/lua] The 'mpack' lua package is required for building Neovim
CMake Error at CMakeLists.txt:459 (message):
A suitable Lua interpreter was not found.
This is for when the whole configuration runs (i.e. after `make
distclean`), afterwards only one Lua interpreter gets checked only.
closes#7239
The old behaviour was to set CMAKE_INSTALL_MANDIR to /usr/local/man
when MANPREFIX wasn't defined. This caused mismatching installation
paths when the installation prefix wasn't /usr/local.
This fix explicitely checks that the prefix is /usr/local to change
the value of CMAKE_INSTALL_MANDIR, and uses the default behaviour
otherwise, as /usr/local is the exception rather than the norm
(as per man hier(7)).
Handling of process exit is still broken. It detects the moment when the
child process exits, then quickly stops polling for process output. It
should continue polling for output until the agent has scraped all of the
process' output. This problem is easy to notice by running a command like
"dir && exit", but even typing "exit<ENTER>" can manifest the problem --
the "t" might not appear.
winpty's Cygwin adapter handles shutdown by waiting for the agent to close
the CONOUT pipe, which it does after it has scraped the child's last
output. AFAIK, neovim doesn't do anything interesting when winpty closes
the CONOUT pipe.
Tests that check localized error messages need a stable locale, else
errors like this occur:
[ FAILED ] 2 tests, listed below:
[ FAILED ] ...npack/file/vim/neovim/test/functional/eval/null_spec.lua @ 29: NULL list is accepted as an empty list by writefile()
...npack/file/vim/neovim/test/functional/eval/null_spec.lua:30: Expected objects to be the same.
Passed in:
(string) '
E484: Cannot open file Xtest-functional-viml-null'
Expected:
(string) '
E484: Can't open file Xtest-functional-viml-null'
stack traceback:
...npack/file/vim/neovim/test/functional/eval/null_spec.lua:30: in function <...npack/file/vim/neovim/test/functional/eval/null_spec.lua:29>
[ FAILED ] ...k/file/vim/neovim/test/functional/ex_cmds/write_spec.lua @ 81: :write errors out correctly
...k/file/vim/neovim/test/functional/ex_cmds/write_spec.lua:97: Expected objects to be the same.
Passed in:
(string) 'Vim(write):E510: Cannot make backup file (add ! to override)'
Expected:
(string) 'Vim(write):E510: Can't make backup file (add ! to override)'
stack traceback:
...k/file/vim/neovim/test/functional/ex_cmds/write_spec.lua:97: in function <...k/file/vim/neovim/test/functional/ex_cmds/write_spec.lua:81>
10 SKIPPED TESTS
2 FAILED TESTS
-- Output to stderr:
2017/07/29 00:41:32 ERROR 31133/open_log_file:170: Logging to stderr, failed to open $NVIM_LOG_FILE: Xtest-startup-xdg-logpath/nvim/log
2017/07/29 00:41:32 WARN 31133/call_set_error:815: RPC: ch 1 was closed by the client
CMake Error at /home/shlomif/Download/unpack/file/vim/neovim/cmake/RunTests.cmake:50 (message):
Running functional tests failed with error: 1.
FAILED: CMakeFiles/functionaltest
cd /home/shlomif/Download/unpack/file/vim/neovim/build && /usr/bin/cmake -DBUSTED_PRG=/home/shlomif/Download/unpack/file/vim/neovim/.deps/usr/bin/busted -DLUA_PRG=/home/shlomif/Download/unpack/file/vim/neovim/.deps/usr/bin/luajit -DNVIM_PRG=/home/shlomif/Download/unpack/file/vim/neovim/build/bin/nvim -DWORKING_DIR=/home/shlomif/Download/unpack/file/vim/neovim -DBUSTED_OUTPUT_TYPE=nvim -DTEST_DIR=/home/shlomif/Download/unpack/file/vim/neovim/test -DBUILD_DIR=/home/shlomif/Download/unpack/file/vim/neovim/build -DTEST_TYPE=functional -DSYSTEM_NAME=Linux -P /home/shlomif/Download/unpack/file/vim/neovim/cmake/RunTests.cmake
ninja: build stopped: subcommand failed.
Makefile:102: recipe for target 'functionaltest' failed
make: *** [functionaltest] Error 1
- Do not delete it: may need to inspect it after tests finished.
- Avoids writing to stderr in cases where the test-local $XDG_DATA_HOME
was not created yet.
This also removes LINT_FILE environment variable, other then that functionality
is kept. It is expected that developers needing partial linting will use `make
lint`, touching interesting file before (if not done already by writing to
them).
Allows linting only modified files and linting multiple files in
parallel. In the current state is rather slow because errors.json is
a 6 MiB file and needs to be reparsed each time.
Results on my system (6-core):
# In build dir, actually parallel
make -j5 clint 241.24s user 8.39s system 334% cpu 1:14.74 total
# In root, one process
make -j5 clint 60.69s user 0.37s system 93% cpu 1:05.19 total
In both cases download time included.
That is not well for travis (though I would keep travis as-is because
new variant will fail before checking all files), but already good
enough for regular development: total times are nearly identical and
this is the *full* build, further `make -C build clint` will check only
modified files.
- Add support for TEST_FILE to the `oldtest` target, for consistency
with the busted/lua tests.
Caveat: with the busted/lua tests TEST_FILE takes a full path, whereas
for `oldtest` it must be "test_foo.res".
- Add support for NVIM_PRG, again so that all test-related targets are
consistent.
- Use consistent name for NVIM_PRG. But still need to support NVIM_PROG
for QuickBuild CI.
Note: The `oldtest` target is driven by the top-level Makefile, because
it requires a TTY. CMake 3.2 added a USES_TERMINAL flag to
add_custom_target(). But we support CMake 2.8...
add_custom_target(oldtest
COMMAND make clean
COMMAND make NVIM_PRG=$<TARGET_FILE:nvim> $ENV{MAKEOVERRIDES}
DEPENDS nvim
WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}/src/nvim/testdir"
USES_TERMINAL true
)
This was a workaround from long ago, but it doesn't seem to be needed
anymore. And it breaks the $PATH on the Windows build (AppVeyor CI).
After this change python3 (and 2) is correctly detected on AppVeyor CI.
References #5946
In Windows Lua's os.tmpname() returns relative paths starting with \s,
prepend them with $TEMP to generate a valid path.
In OS X os.tmpname() returns paths in '/tmp' but they should be in
'/private/tmp'. We cannot use os_name() for platform detection because
some tests use tempname() before nvim is spawned, instead use one of the
following:
1. Set SYSTEM_NAME environment variable before calling the tests, it
is set from CMAKE_SYSTEM_NAME(i.e. uname -s or 'Windows')
2. Call uname -s
3. Assume windows
Using /MT was causing issues when building luarocks, revert it, use the
dynammic runtime and generate release DLLs for the dependencies.
Some refactoring was required because for linking cmake looks for the
import libraries (.lib) but on runtime executables we need the .dll files
to be in the same folder.
The DLLs are placed in the bin/ folder in order for nvim.exe to run
during the build and tests. The install target installs the DLLs with
the nvim binary - uses GetPrerequisites to find runtime DLLs.
Some minor issues that required adjustments:
- [MSVC] FindMsgpack.cmake now looks for msgpack_import.lib instead of
msgpack.lib
- The lua-client fails to find libuv.lib, instead it looks for uv.lib,
added second copy of the file to the install command.
- [MSVC] CMAKE_BUILD_TYPE affects the output paths, default to Release.
Part of these changes are credited to @jasonwilliams200OK who fixed the
third-party recipes to consistently use the same build type.
Otherwise, busted may run a different interpreter than the one we
detected, without the capabilities we expect. (For instance, we might
have detected the luajit interpreter, but busted might run the lua
interpreter, without the ffi module.)
By default Neovim searched a Luajit instalation and linked against
the luajit library.
In practice Neovim only requires luajit to run the unit tests. All other
targets only require lua and the correct lua modules. This commit:
1. Remove the strict dependency on Luajit
2. Makes the unittest target depend on the lua 'ffi' module.
If the module is not available the target is not enabled
and a message is displayed.
By default, find_library() searches all directories for one possible
name and then looks for the next name. To make sure we're building
against the same headers and libraries, look for all names in a
directory before moving to the next one.
In 33bc332, version constraints were added to pkg_search_module(), but
that only affects the set of directories searched by
find_library()/find_path().
Once the header directory is found, parse the version from
version_master.h so it can be checked by the find_package() call in the
root CMakeLists.txt.
libmsgpack was the old C++ library provided by msgpack-c. The C library
is libmsgpackc.
The C++ support became header-only, but there was a bug
(msgpack/msgpack-c#395) wherein using msgpack-c's CMake build system
would only install libmsgpack instead of libmsgpackc.
Searching for both libraries, but preferring libmsgpackc, allows for
building against older msgpack-c releases and prepares for the upcoming
msgpack-c release which fixes the aforementioned issues.
Signed-off-by: James McCoy <jamessan@jamessan.com>
When building for X86 the CMake check_library_exists always fails to find
functions from the Win32 API due to name mangling conventions. The convention
for API functions is __stdcall and the CMake test code assumes __cdecl. Since
these are libraries from the Windows API we can simply link against the
libraries without checking for the functions.
Before this change, building Neovim would recursively search parent
directories for a .git directory. If Neovim was downloaded as a tarball
(i.e. without a .git directory), but placed in a subdirectory of
a Git repository, this caused a CMake error. Such a situation could
occur when packaging Neovim, for example.
Unfortunately, the previous attempt in #3317 did not fix this problem.
* Split build steps to utilize the Travis build lifecycle.
* Move shell code from `.travis.yml` into Bash files in `.ci/`,
one file for each step of the Travis build lifecycle.
* Use configuration variables in `.travis.yml` to change
build behavior (e.g. build 32-bit with `BUILD_32BIT=ON`).
* Keep all configuration in environment variables in
`.travis.yml`. In scripts, concatenate environment variables
according to configuration to change to different behavior.
* Add GCC 5 builds for Linux.
* Use Travis's caching feature [1] for third-party dependencies
and pip packages.
* Allow failures MSan, as the errors it reports have to be
fixed first.
Valgrind is still disabled, but can be enabled by setting
`env: VALGRIND=ON` for a job in `.travis.yml`.
[1] http://docs.travis-ci.com/user/caching
Piping input into nvim causes the helptags generation to hang. For
example, the following does not work:
yes | nvim -c "helptags ."
The helptags are generated during installation with a command similar
to the one above, using CMake's execute_process to call nvim.
As execute_process does not use an intermediate shell, the following
will cause the installation to hang:
yes | make install
pacaur, an Arch Linux package helper, uses a similar command to
install packages [1], and thus can currently not be used to install
Neovim.
This commit adds a workaround to GenerateHelptags.cmake to circumvent
this problem.
[1] 22c00a3d05/pacaur (L825)
For now, only install man pages matching "nvim*.1": we don't want to
install xxd.1 as it might conflict with that of a user's Vim
installation.
closes#1826
Reviewed-by: Florian Walch <florian@fwalch.com>
Helped-by: John Szakmeister <john@szakmeister.net>
Jemalloc will be used if the cmake option `USE_JEMALLOC` is enabled(which is the
default). To avoid trouble with clang's ASAN, it is disabled by default if the
`SANITIZE` option is enabled.
Since jemalloc has thread cache for small objects, it fills the gap created by
removing klib memory pools.
The `xstrdup` funciton(memory.c) had to be reimplemented on top of `xmalloc` to
make it work with a custom allocator.
- Read TEST_TAG/TEST_FILTER env vars from cmake/RunTests.cmake. Setting these
environment variables will pass --tags/--filter to busted, which can used to
filter which tests are executed.
- Remove calls to nvim msgpack-rpc API outside tests. This removes the
requirement of having a static `clear` call in test/functional/helpers.lua
- Use the new busted command-line option "--lazy" to ensure the setup/teardown
hooks are only executed when a suite runs at least one test.
Now its possible to run/debug a single test like this:
```sh
TEST_FILTER='some test string' make test
```
Which will only run tests containing "some test string" in the title.
Another option is:
```sh
TEST_TAG=some-tag make test
```
After putting #some-tag into the test title. This also improves debugging
experience because there will be no unnecessary gdbserver instances whe GDB=1 is
passed.
This requires a couple of extra modules that are not installed by
default, and it requires capturing stdout of the tests--otherwise CMake
output is intermixed with the XML output of busted.
It turns out that Busted started cleaning the environment in 2.0rc5 as a
result of Olivine-Labs/busted#62. This, in turn, caused the ffi module
to be reloaded for each spec file, and LuaJIT doesn't appreciate it.
The net effect is an assertion error in LuaJIT.
By using the --helper feature of Busted, we can pre-load some modules
ahead of Busted and prevent it from reloading them--making LuaJIT happy
again.
On some systems, such as NetBSD, the gettext header is tucked under the
gettext directory in the system include area. Let's add a path suffix
to ensure we correctly discover the header on such systems.
It turns out that CMake always canonicalizes `CMAKE_INSTALL_PREFIX` to
an absolute path--if it's a relative path, it canonicalizes it relative
to the build directory. As a result, the only thing the DESTDIR and
relative directory check prevents is an installation into the root
directory since CMake strips the trailing slash, turning "/" into an
empty string. Let's just remove the check all together, since it cannot
accomplish what we intended.
It turns out that `file(INSTALL ...)` already accounts for `DESTDIR`, so
this wasn't creating the directory structure in the correct location.
Instead, we need to do our existence check with `DESTDIR`, but leave it
off when doing the install step.
While we're at it, add a check to make sure `ENV{DESTDIR}` is not being
used with a relative path, as that construct doesn't make much sense.
This fixes issue #1387 discovered while trying to make helptag
generation work correctly in #1381.
If you aren't just building everything into build/, then the functional
tests fail because they can't find the nvim executable. Let's pass in
the location of the nvim executable, and set NVIM_PRG environment
variable accordingly.
Now that the lua client is available, python/lupa are no longer necessary to run
the functional tests. The helper functions previously defined in
run-functional-tests.py were adapted to test/functional/helpers.lua.
- cmake: git_timestamp() returns last commit time formatted as
`YYYYMMddHHmm`.
- Always include commit hash in :version and --version output.
`nvim --version` sample output:
NVIM 0.0.0-alpha+201410070245 (compiled Oct 7 2014 05:30:45)
Commit: f747b2b1ff7bfe7eb00cc2be82d7af87c98f1111
Busted can only discover tests from a single directory. In order to allow tests
under 'legacy' to run as a functional test, it needed to be moved to
'test/functional'.
The 'lupa' python package provides a simple way to seamless integrate lua and
python code.
This commit replaces vroom by a python script that exposes the 'neovim' package
to a lua state, and invokes busted to run functional tests. This is a temporary
solution that will enable writing functional tests using lua/bused while a lua
client library is not available.
The reason for dropping vroom is flexibility: Lua/busted has a nice DSL-style
syntax while also providing the customization power of a full programming
language. Another reason is to use a single framework for unit/functional tests.
Two other changes were performed in this commit:
- Instead of "gcc-unittest/gcc-ia32", the travis builds for gcc are now
identified by "gcc/gcc-32". They will run unit/functional tests for both 64
and 32 bits.
- Old integration tests(in src/nvim/testdir) are now ran by the 'oldtest' target
The install() command will create the parent directories, but it does so
with the user's umask. We want to do our best to make sure the correct
permissions are being set, without clobbering existing permissions.
To do this, this commit introduces an install_helper(), which is similar
in signature to the install() command, to help ensure that directories
are created ahead of the actual install() command. This will attempt to
use 0644 permissions for files and 0755 permissions for directories by
default--though they can be overridden.
To make this work correctly, without trying to introduce some mechanism
with setting the umask, it meant that there's a small portion that makes
use of an "internal" version of the file() command. It has been tested
on CMake 2.8.11, 2.8.12, and 3.0.2, and works correctly on all versions.
This fixes#1201 and #1086.
Using msgpack v5 will let nvim be more compatible with msgpack libraries for
other platforms.
This also replaces "raw" references by "bin" which is the new name for msgpack
binary data type
Fixes#902: localization build: `install`, `uninstall`, `prefixcheck
targets. All the language-related bits will now build under CMake.
Changes include:
* Moving all non-generated sources into the NEOVIM_SOURCES variable
to aid in generating the .pot file.
* Moving a couple generated sources from NEOVIM_SOURCES and into
NEOVIM_GENERATED_SOURCES.
* Added NEOVIM_HEADERS to the executable and the library for folks who
are using something other than Ninja or makefiles (that way the
headers will show up in the IDE files).
* Now uses gettext's `--update` switch to update the .po files, rather
than doing a fragile `mv` dance that could leave you with a broken
working tree if you press CTRL-C at the right time.
* Creates `update-po-${LANG}` targets for updating individual
languages, just like the original Makefile.
* Also adds the `update-po` target for updating all the languages.
* Ported the `check-${LANG}` style targets. They're
`check-po-${LANG}` under CMake.
* Handles all the one-off instances that were in the original
Makefile. Fixed up ko.UTF-8.po to include the "Original
translation" line like other .po files to make the generation of the
"Generate from ..." comments consistent. Updated ko.po with the new
text.
Fixes#902: localization build: `install`, `uninstall`, `prefixcheck
targets. All the language-related bits will now build under CMake.
Changes include:
* Moving all non-generated sources into the NEOVIM_SOURCES variable
to aid in generating the .pot file.
* Moving a couple generated sources from NEOVIM_SOURCES and into
NEOVIM_GENERATED_SOURCES.
* Added NEOVIM_HEADERS to the executable and the library for folks who
are using something other than Ninja or makefiles (that way the
headers will show up in the IDE files).
* Now uses gettext's `--update` switch to update the .po files, rather
than doing a fragile `mv` dance that could leave you with a broken
working tree if you press CTRL-C at the right time.
* Creates `update-po-${LANG}` targets for updating individual
languages, just like the original Makefile.
* Also adds the `update-po` target for updating all the languages.
* Ported the `check-${LANG}` style targets. They're
`check-po-${LANG}` under CMake.
* Handles all the one-off instances that were in the original
Makefile. Fixed up ko.UTF-8.po to include the "Original
translation" line like other .po files to make the generation of the
"Generate from ..." comments consistent. Updated ko.po with the new
text.
- Defined CMake checks for all headers in config.h.in
- Removed headers checks that are not used anymore:
sgtty.h sys/statfs.h libintl.h poll.h
- Added UNIX check
- Add some fatal checks
+ Check for setenv() and fail if it does not exist
since our os layer just assumes it does
+ lstat is required by os_unix.c
+ sys/wait.h is required in UNIX
- Removed entries for functions that are not being used: getcwd,
getrlimit, getwd, nanosleep, sigaltstack, getwd, sigstack, fseeko
- Replaced nearly all defines in config.h.in for functions with
compile time checks
- Add check for symbol FD_CLOEXEC
- Add check for langinfo CODESET
- HAVE_ICONV_H and HAVE_ICONV hold the expected checks but Neovim uses
USE_ICONV define to actually decide whether to enable it
- Removed checks that are no longer needed
+ USEMEMMOVE
+ _FILE_OFFSET_BITS
+ HAVE_ST_BLKSIZE
+ dlfcn.h
- Unittest should contain substring '_spec' in filename.
- This is the simplest way to use both lua and moonscript tests.
- This prevents running of non-test scripts from test folder.
This is in preparation for the next step, which is to find a suitable
lua interpreter, rather than just erroring when an interpreter is found
but doesn't have the necessary dependencies.
Helped-by: John Szakmeister <john@szakmeister.net>
This allows us to avoid hard-coding paths and using environment
variables to communicate key information to unit tests, which fits
with the overall goal of making sure that folks driving CMake directly
can continue to do out-of-tree builds.
With this, you can now run a single unit test file using:
TEST_FILE=/path/to/file make unittest
For example, to just run the path unit tests, you can do:
TEST_FILE=test/unit/path.moon make unittest
- Build targeting 32-bit with travis
- Code in `before_install`/`after_success` was moved to travis.sh since it
provides greater flexibility for detecting the build matrix environment. This
improves the build speed since we now install only what's necessary.
- Now clint has a dedicated travis worker
Apparently busted 1.11.0 is broken(https://github.com/Olivine-Labs/busted/issues/236)
in a way that is causing the unit tests to fail. This pins the version to 1.10.0
and also fixes a wrong variable set when msgpack was added as a dependency
Since libuv.pc is broken at the moment, try to determine libuv's
dependencies ourselves. This ports most of the checks from libuv into
our CMake build, and fixes the build on other unix platforms.
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.
If LibUV_USE_STATIC is set then the static libuv library will be
preferred to the shared library. This is useful when building with the
bundled libuv but is less useful when building with a system libuv.
Explicitly try to find the static libuv library first.
This might be considered a hack and if it weren't a single-use module it
might be preferable to control static versus shared preferences with a
configuration variable.
