| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
compat53 is vendored since #1757 as it is required to run luarocks with lua 5.1 or 5.2.
However, this introduced some issues as the GNUmakefile install rule places these in the same place where `luarocks install compat53` would install them. This means you get conflicts if you install the actual package:
```
Warning: /.../prefix/share/lua/5.1/compat53/init.lua is not tracked by this installation of LuaRocks. Moving it to /.../prefix/share/lua/5.1/compat53/init.lua~
Warning: /.../prefix/share/lua/5.1/compat53/module.lua is not tracked by this installation of LuaRocks. Moving it to /.../prefix/share/lua/5.1/compat53/module.lua~
Warning: /.../prefix/share/lua/5.1/compat53/file_mt.lua is not tracked by this installation of LuaRocks. Moving it to /.../prefix/share/lua/5.1/compat53/file_mt.lua~
```
It is also not ideal for linux package maintainers to include a vendored package, see: https://github.com/luarocks/luarocks/pull/1757#issuecomment-3409873412.
To solve these issues, this patchset makes the following changes:
- GNUmakefile now places the compat53 files under `luarocks/vendor/compat53` (which is added internally to the luarocks script's `package.path`). This way a user's installation of compat53 does not interfere at all with luarocks one.
- Added `--with-system-compat53` option to configure script for external packaging systems.
- Fixed install.bat's logic for deciding whether to vendor compat53, as the current script includes it for every version.
install.bat already places luarocks sources outside of LUAPATH, so that part can stay as is.
I've also inverted the version check to avoid the need for future patches like: #1850.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This is to match the behavior of luarocks.deps
|
| | |
|
| |
|
|
| |
This commit enables luarocks to be configured and build on OpenBSD.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
* Do not set again variables that were set in config.unix
* Do not re-detect the Lua version after configure already did it
* Remove --luarocksconfdir, use --sysconfdir only
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Support using any interpreter name, even if it doesn't start with
'lua'.
|
| |
|
|
|
|
| |
This change results in a default config that works in both LuaRocks 2 and 3.
We do not promise a compatible configuration format, but it's nice to avoid
unnecessary breakage if we can.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Verification of the Lua include path happens at LuaRocks runtime,
but we also perform it here just so that the user gets an early failure
if they try to install LuaRocks with the Lua interpreter package
but not the "development files" that many Linux distros ship separately.
We also include a --disable-incdir-check flag for specialized scenarios: if
you do not wish to use "luarocks build", (e.g. when only deploying binary
packages) you do not need lua.h installed. This flag skips the check for lua.h
in "configure".
|
| |
|
|
|
|
|
|
|
|
| |
* Reworked configure script
* Now passes shellcheck
* New Makefile for Unix
* Simplified `make` and `make install` targets
* Simplified `make bootstrap` target
* New targets `make binary` and `make install-binary`
build and install an all-in-one binary of LuaRocks
|
| | |
|
| |
|
|
|
|
|
|
| |
Let's take the opportunity of a new major version to make an important cleanup: getting rid of the error-prone unversioned configuration files. This drops support for:
* Unversioned config.lua -> use config-5.x.lua
* Unversioned luarocks/site_config.lua -> it always generates luarocks/core/site_config_5_x.lua
* Unversioned lib/luarocks/rocks -> it always uses lib/luarocks/rocks-5.x
|
| |
|
| |
Fixed wrong "interp" instead of "where" in the configure file
|
| |
|
|
|
|
|
|
|
|
| |
This avoids in practice a problem that occurs in this scenario:
1. user installs Lua 5.1, gets lua and lua5.1 binaries
2. user installs LuaRocks, it detects and uses lua
3. user installs Lua 5.2, gets lua and lua5.2 binaries (lua is replaced)
4. user installs LuaRocks with --lua-version=5.2, it detects and uses lua
5. luarocks-5.1 now uses lua, which is Lua 5.2, rockspecs get passed the wrong value of $(LUA)
|
| | |
|
| |
|
|
|
| |
(e.g. allow it to find `lua5.1` when lua is 5.3 and only `--lua-version=5.1`
is given).
|
| |
|
|
|
| |
Ravi has "Ravi 5.3" as _VERSION. Don't use _VERSION:sub(5) to get Lua
version, match " (5%.[123])$" instead.
|
| | |
|
| |
|
|
|
|
| |
which returns path to the program, not to the directory containing it.
That causes errors when configuring without --with-lua.
The fix is to apply 'dirname' if 'command -v' was a success.
|
| |
|
| |
Seems like `command -v` is defined by POSIX and therefore should be compatible with all POSIX OSes.
|
| |
|
| |
Look for executable path using system utility `which` instead of fragile regular expressions. See $447 for details. Also see discussion in [neovim](https://github.com/neovim/neovim/issues/3620#issuecomment-154757577) issues.
|
| | |
|
| |
|
|
|
|
| |
correct.
Closes #293.
|
| | |
|
| |
|
|
| |
Error messages were even already using it by accident!
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
HTTPS is set as default for uploading.
HTTP is still default for downloading to keep dependencies low and because the
HTTPS code is new; might be changed in the future.
See #273 and #240.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Should improve on behavior mentioned at
http://stackoverflow.com/questions/20321560/how-do-install-libraries-for-both-lua5-2-and-5-1-using-luarocks/20359102?noredirect=1#comment30696438_20359102
|