| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 #1446.
|
|
|
|
|
|
|
| |
Reduce some variable aliasing, just in case this is what is triggering
possible LuaJIT bugs on the MIPS-based LoongArch architecture.
See #1553.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
| |
Fixes #1357.
|
|
|
|
| |
Fix a problem where 'files' were being sorted even though they should have
been inspected in the order of external_deps_patterns.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Previously, if LUA_INCDIR was specified but invalid, install and other
commands would error without a message, eventually causing a failed
assertion in cmd.lua and leaving a hard-to-troubleshoot situation
with no information.
|
| |
|
| |
|
| |
|
|
|
|
| |
This commit enables luarocks to be configured and build on OpenBSD.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support for pinning dependencies in projects and rocks:
* Adds a new flag called `--pin` which creates a `luarocks.lock`
when building a rock with `luarocks build` or `luarocks make`.
This lock file contains the exact version numbers of every
direct or indirect dependency of the rock (in other words,
it is the transitive closure of the dependencies.)
For `make`, the `luarocks.lock` file is created in the current
directory.
The lock file is also installed as part of the rock in
its metadata directory alongside its rockspec.
When using `--pin`, if a lock file already exists, it is
ignored and overwritten.
* When building a rock with `luarocks make`, if there is a
`luarocks.lock` file in the current directory, the exact
versions specified there will be used for resolving dependencies.
* When building a rock with `luarocks build`, if there is a
`luarocks.lock` file in root of its sources, the exact
versions specified there will be used for resolving dependencies.
* When installing a `.rock` file with `luarocks install`, if the
rock contains a `luarocks.lock` file (i.e., if its dependencies
were pinned with `--pin` when the rock was built), the exact
versions specified there will be used for resolving dependencies.
|
|
|
|
| |
Only check for availability of a rock for other Lua versions
if the user explicitly requests so.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
This reduces the complexity of the interaction between
build-time configuration, run-time auto-detection, and overrides via
CLI flags. The LuaJIT version is now always auto-detected at run-time
based on the Lua interpreter currently configured, based on the values
of configuration options `variables.LUA_BINDIR` and `lua_interpreter`.
|
| |
|
| |
|
|
|
|
|
|
| |
The --verify options of build and make check the signature of
rockspec and src.rock files; the --sign option is meant to
be used alongside --pack-binary-rock.
|
|
|
|
|
| |
This is especially important now that the Lua library paths
are detected using the dependency check machinery.
|
| |
|
|
|
|
| |
This matches the change done in #872.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Move logic from install.bat for resolving LUALIB (the name of the Lua
library) reusing the standard LuaRocks functionality for finding
external dependency libraries.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* `--lua-dir` flag, specifying a prefix for the Lua installation to
be used. This reconfigures LuaRocks entirely, including allowing
a LuaRocks which is itself running using one Lua 5.x version to
manage packages for a different Lua 5.y version. The resulting
configuration can be checked with `luarocks config --lua-dir=<path>`.
* requiring `luarocks.core.cfg` no longer has side-effects
* configuration now needs to be initialized with `cfg.init([lua_data])`,
where `lua_data` is a table with the configuration of the VM:
* `lua_version` - e.g. `"5.3"`
* `luajit_version` - e.g. `"2.1.0-beta3"`
* `lua_interpreter` - e.g. `"lua5.3"`
* `lua_bindir` - e.g. `"/usr/local/bin"`
* `lua_libdir` - e.g. `"/usr/local/lib"`
* `lua_incdir` - e.g. `"/usr/local/include/lua-5.3"`
* `cfg.init` can be called multiple times, reconfiguring the global state.
This is important since `luarocks.loader` now calls it, and the `--lua-dir`
command line can override the configuration and reconfigure LuaRocks.
* `site_config_*` is no more: LuaRocks is no longer dependent on a properly-written
site_config file. Instead, it can *optionally* use `luarocks.core.hardcoded`
for hardcoded values, or detect its configuration at runtime, based on
OS detection, arg[-1] or command-line flags.
* reduction of moving parts in the configuration:
* `cfg.platforms` is no longer a globally-visible table; instead, `cfg`
provides an API of read-only functions: `is_platform`, `each_platform`,
`print_platforms`.
* `cfg.*_proxy` options are no longer configured via the config files,
but rather via the standard `*_proxy` environment variables.
* `"windows"` is now the more general platform name of the Windows family.
This is technically a breaking change but I don't expect it to cause
problems with real-world rockspecs.
* internal code reorganization in `luarocks.cmd` module
|
|
|
|
|
|
|
|
| |
autogenerate it
The approach is slightly ugly since it adds builtin-specific
knowledge to `luarocks.deps`, but I don't think any other
build backends will support this behavior any time soon.
|
|
|
|
|
|
|
|
|
|
| |
Adds a Rockspec object responsible for constructing all Rockspec
tables in the manner of the Queries and Results objects, and
a type-checked Build.Opts tables for build options, since
the number of attributes passed around was getting out of hand.
This allowed a major cleanup in the luarocks.build,
luarocks.fetch and luarocks.cmd.write_rockspec modules.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Adds the `build_dependencies` key to the rockspec format,
for dependencies that are only triggered when building from
source (e.g. via `luarocks build` or running `luarocks install`
on a rockspec) and not when building from a packaged `.rock`
file using `luarocks install`.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add asserts to uses of `name` arguments to check that they
are not namespaced; rename namespace-able name arguments
to `ns_name` and avoid some unrelated uses of the `name`
argument that don't represent rock names (there are still
others around, to be fixed eventually).
This may cause some failures in some untested code paths
with namespaced packages, but we hope to catch them
with better testing. Better to be safe here than to
perform filesystem operations on incorrect paths.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For details of the new feature, see
https://github.com/luarocks/luarocks/wiki/Namespaces
This ended up being a huge commit because of some major refactoring
motivated by the new feature:
* new modules for some object types:
* `luarocks.queries` - all functions that look for rocks in local or
remote repositories now use objects constructed by this module:
query objects contain the name, namespace and query constraints.
Dependencies in a rockspec are also stored as query objects.
* `luarocks.results` - all individual results produces from queries
are returned in this format: result objects contain the name,
namespace, version, arch and repo.
* the `results` object was renamed to `result_tree`, to better
reflect that it is not an array of `result` objects.
* `luarocks.vers` was removed, its functionality was moved to better locations.
Specifically on namespaces:
* Commands that take a rock `name` can now take `namespace/name`
(and alternately `--flags=namespace` so that URLs can be
also installed with a nominal namespace).
* Rocks installed from a namespace now create a `rock_namespace`
file alongside `rock_manifest`, which is used when matching
namespaced dependencies against locally-installed rocks.
* Using namespaced dependencies in a rockspec, requires
`rockspec_format = "3.0"`.
* Tests under the `#namespaces` hashtag, all using a local repository.
|