| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
|
|
|
| |
Fixes #1055.
|
| |
|
|
|
|
| |
Fixes #1038.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
This should be more flexible than hardcoding a value that
may become incorrect once people reconfigure their LuaRocks
to point to another Lua distribution, especially on Windows.
Fixes #905.
|
|
|
|
|
|
|
| |
* do not proceed with commands if interpreter is not found
* begin retiring LUA_DIR and LUA_BINDIR, and promote LUA as
the main way to setup the interpreter location (from which
we derive the rest)
|
| |
|
|
|
|
| |
Fixes #924.
|
|
|
|
| |
Thanks to @imolein for pointing it out!
|
| |
|
| |
|
|
|
|
|
|
|
| |
This only applies to 'builtin' as we can't know about other modes,
but this should be good enough.
Fixes #1275.
|
| |
|
|
|
|
| |
Fixes #1261.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a rockspec specifies `external_dependencies` but those don't define
a `library` entry, we don't have a way to check for the various
possible `external_deps_subdirs` to find the one that contains the library.
(But people really should specify a `library` entry there if they're
linking the library!)
Previously, we were just picking the first one from the list.
On Windows, this meant that sometimes setting `MY_DEPENDENCY_DIR` would
not be sufficient if the library was under `$MY_DEPENDENCY_DIR/lib`,
because "" was picked first. We now improve the heuristic by putting "lib"
first on the list and checking if it exists.
I'm still keeping "bin" in the end of the list, because I think this
is less common that a flat directory structure on Windows, so "lib"
covers the Unix-like trees and "" covers flat trees (I don't remember
why have "bin" as a library subdir on Windows, but if it's there then
we must have seen it in the wild!) This means that "bin" will never
get auto-picked by this heuristic, but it will be available for the
cases where `library` _is_ set.
While I'm at it, I also flipped the order of some Unix entries, so that
this heuristic for these kind of rockspecs gets a nicer behavior on
Unix systems that have things like `/usr/lib64` and `/usr/lib/<platform>`
as well.
Fixes #1041.
|
|
|
|
| |
Fixes #1492.
|
|
|
|
|
|
| |
Fixes #1243.
Fixes #1168.
Fixes #559.
|
|
|
|
| |
Fixes #1446.
|
|
|
|
|
| |
Avoid showing things like `/foo/bar/../.././lua_modules` when
running `luarocks path`.
|
|
|
|
|
|
|
|
|
|
|
| |
By default, `--lr-path` and `--lr-cpath` only include the paths derived by the
LuaRocks rocks_trees. Using `--full` includes any other components defined in
your system's package.(c)path, either via the running interpreter's default
paths or via `LUA_(C)PATH(_5_x)` environment variables (in short, using
`--full` produces the same lists as shown in the shell outputs of `luarocks
path`.
Closes #1351.
|
|
|
|
|
|
| |
Fixes #1001.
Thanks @badrazizi for the suggestion!
|
|
|
|
|
|
|
|
|
| |
Not sure of what are the circumstances that make this cause problems on
Windows, but running this shouldn't be necessary on Windows, since the concept
of "execute permissions for directories means traversal permissions" is a
Unixism.
Fixes #991.
|
| |
|
|
|
|
| |
...to get rid of the GitHub Actions warning about Node.js 16
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a rockspec has external_dependencies but the module entry does
not specify incdirs or libdirs, then autoextract those values from
external_dependencies and apply it to the module entry.
Hopefully this will improve compatibility of existing rockspecs
that did not fully specify their incdirs and libdirs, such as
https://github.com/brimworks/lua-yajl/blob/078e48147e89d34b8224a07129675aa9b5820630/rockspecs/lua-yajl-2.0-1.rockspec
Fixes #1239.
|
|
|
|
| |
Fixes #1202.
|
| |
|
|
|
|
| |
Fixes #1414.
|
|
|
|
|
|
|
|
|
|
| |
LuaRocks does not validate the contents of the build table
because each backend defines it on this own. These validations
should be enough to address #1477, but ideally each bundled
`build` backend should have its own validator like the one
on `luarocks.type.rockspec`.
Fixes #1477.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When installing build dependencies, do so for the Lua version on which the
LuaRocks program is actually running, and not the one selected by the user via
config or `--lua-version`.
To do that, we temporarily flip the user-selected Lua version. It's a hacky
approach because we have to do this by flipping a bunch of global config
settings, and we may be missing some entries.
This definitely needs a better solution, but this is what can be done somewhat
easily in the current architecture. A full solution needs to address have
several complications (e.g. if you have a build dependency that needs to be
compiled, it will require C headers for another version of LuaRocks, and the
binary might be compiled with a different Lua version than the one the
developer has set up in their machine.)
|
|
|
|
| |
Fixes #1512.
|
|
|
|
| |
Closes #1513.
|
|
|
|
|
|
| |
Closes #1514.
Co-Authored-By: FractalU <r.beckmann@protonmail.com>
|
|
|
|
|
|
| |
Thanks @RunsFor for the suggested workaround!
Fixes #1529.
|
|
|
|
|
|
|
| |
Reduce some variable aliasing, just in case this is what is triggering
possible LuaJIT bugs on the MIPS-based LoongArch architecture.
See #1553.
|
|
|
|
| |
Fixes #1559
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
I couldn't track down which scenarios cause this, but it has
happened on Windows:
See: https://github.com/lunarmodules/luasystem/pull/17
See: https://github.com/lunarmodules/luasystem/actions/runs/7907096563/job/21583369125?pr=17
|
|
|
| |
Fixes #1540
|
| |
|
|
|
|
| |
Fixes #1545
|
|
|
|
| |
* Fixes a crash in `fulfill_dependency()` on musl
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
As mentioned by @erw7 in
https://github.com/luarocks/luarocks/issues/1443#issuecomment-1483816481,
quotes is required when using io.popen but causes problems when using
io.iopen. This makes luarocks unable to find its own md5sum.exe it is
shipped with.
Fixes https://github.com/luarocks/luarocks/issues/1443
Fixes https://github.com/neovim/neovim/issues/22752
Co-authored-by: erw7 <erw7.github@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Ignore any extra version info in jit.version when separated by a space.
A normal LuaJIT jit.version string looks like "LuaJIT 2.1.0-beta3".
Since official LuaJIT releases have all but stopped, various forks
continue to use the same version for all forks.
This change allows forks and patched rebuilds to add additional version
information at the end of the string without breaking luarocks version
detection, e.g. "LuaJIT 2.1.0-beta3 some-extra-version-info".
|