LuaRocks 3.x #7
Merged
LuaRocks 3.x #7
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* Skip external commands loading if no external_namespace provided: it is so when a command is run using `tarantoolctl rocks <command>`. * Allow to omit a description field in a rockspec. * Configure more options using hardcoded.lua (it is named as site_config.lua in luarocks-2.x). Based on or inspired by the following commits: - 9f55766 ('Add LUAROCKS_LOCAL_BY_DEFAULT option to site_config.lua'). - e3f7486 ('Allow to override certain values in cfg.lua'). - dba49e0 ('Enable cfg.home_tree even for root'). - 6e6fe62 ('Add site_config.LUAROCKS_LOCALDIR config variable'). The following options are added for hardcoded.lua: - LOCALDIR - LOCAL_BY_DEFAULT - HOMEDIR - HOME_TREE_SUBDIR - LUA_MODULES_LUA_SUBDIR - LUA_MODULES_LIB_SUBDIR - ROCKS_SERVERS The following options are ported from luarocks-2 (and renamed from LUAROCKS_FOO to FOO): - ROCKS_SUBDIR - EXTERNAL_DEPS_SUBDIRS All that options are needed to adjust behaviour of luarocks from tarantool-side hardcoded.lua file. * Detect tarantool and add it to rocks_provided and rocks_provided_3_0. Based on: - 370d173 ('Detect and add Tarantool it to rocks_provided)' * Execute cfg.init() code only once. * Fixed strict mode. Inspired by: - dfaf765 ('Fix strict mode'). * Dropped site_config.lua support: tarantool doesn't use it anymore.
|
Usually we comment a patchset, but here the deadline is near, so I decided to I reverted some of changes, because failed to understood what is a problem and Below I have summarized changes I made for the patchset, its motivation and Re first commit ('Fix compatibility with tarantool static build'):
Re commit 'pass destination dir to unpack rocks archive':
Re commit 'wrap call other loaders in pcall':
Re commit 'stop scanning rocks servers if exact match found':
I'll continue tomorrow. The plan is the following:
|
A module written on C requires tarantool header files. Usually a
rockspec checks for its existence and pass a directory to use inside a
build system (say, cmake).
The check for existence may be performed like so:
| external_dependencies = {
| TARANTOOL = {
| header = 'tarantool/module.h'
| }
| }
While the directory may be passed in this way:
| build = {
| type = 'cmake',
| variables = {
| TARANTOOL_DIR='$(TARANTOOL_DIR)',
| }
| }
Consider 'ckit' branch of 'tarantool/modulekit' repository for a full
example.
The check for external dependencies fails when tarantool is installed
outside of '/usr/ or '/usr/local/' directories. Consider [1] for more
information about the problem.
To fix the problem hardened.PREFIX, which is filled during tarantool
build with CMAKE_INSTALL_PREFIX value, is added to the default value of
'external_deps_dirs' list of directories. Luarocks use this value to
resolve external dependencies.
The patch is based on the following patch for luarocks-2:
- b2dde9a ('[luarocks] Add support for non-standard path')
[1]: tarantool/tarantool#3148
luarocks has support for calculating md5 with 'md5' rock if it's present, but we don't have it in tarantool, and instead have the 'digest' module. That's why luarocks falls back to 'openssl' binary to calculate md5 digests. This patch will allow luarocks to use our internal digests module. (cherry-picked from 92b5f7d)
Tarantool has no separate dynamic library (all necessary symbols are
exposed from its executable file), so we should skip the check for a Lua
dynamic library existence.
Tarantool's headers (such as lua.h) are placed in
${PREFIX}/include/tarantool, but LUA_INCDIR is always set using
hardcoded.lua, so we don't need to adjust find_lua_incdir() code. This
function tries to guess LUA_INCDIR based on LUA_DIR.
(cherry picked from commit b3a046e)
Luarocks tries to detect a Lua interpreter version installed in a system. When this attempt fails it gives a warning that built or installed modules may be configured improperly (say, configured for 5.1, but intended to be run with 5.3). If there are no --lua-ver[sion] and --lua-dir command-line options or corresponding configuration values luarocks still tries to find a Lua interpreter, but fails to give a warning due to concatenation a string with `nil`. The error looks so: > /usr/share/tarantool/luarocks/cmd.lua:392: attempt to concatenate > local 'lua_version' (a nil value)' The patch changes a warning to report a Lua version from a configuration when the command line options are not passed. See luarocks#961
This change eliminates the following warning when tarantool is the only Lua interpreter installed on the system: > Warning: Could not find a Lua interpreter for version 5.1 in your > PATH. Modules may not install with the correct configurations. You may > want to specify to the path prefix to your build of Lua 5.1 using > --lua-dir
Closes tarantool/tarantool#2609 (cherry picked from commit bb42e8b)
|
Updated the PR again. Re commit 'Stop scanning rocks servers if exact match found' (again):
Re commit 'add support for non-standard path':
Re commit 'Use digest.md5_hex to compute md5 digests instead of openssl':
Re commit 'don't check lua when process dependencies':
Re commit 'test: fix reporting failures on 'command' backend':
Re commit 'fix check default lua_version':
Re commit 'fix strange string.match incorrect behavior':
Re commit 'Get rid of useless warning':
I verified tarantool/tarantool#2609 , found the I think that less intrusive and properly described changes allow us to I'll continue today with results of testing of the branch. |
|
I installed the updated version of tarantool into the system (from ebuild on
I don't know how to verify whether it is good or bad.
Everything looks good except the following notes:
Then I step into the directory with clone avro-schema module and made the
diff --git a/avro-schema-scm-1.rockspec b/avro-schema-scm-1.rockspec
index ddb020b..c995d8c 100644
--- a/avro-schema-scm-1.rockspec
+++ b/avro-schema-scm-1.rockspec
@@ -1,3 +1,4 @@
+rockspec_format = '3.0'
package = 'avro-schema'
version = 'scm-1'
source = {
@@ -26,4 +27,8 @@ build = {
TARANTOOL_INSTALL_LUADIR="$(LUADIR)",
},
}
+test = {
+ type = 'command',
+ command = 'cmake . && make && make check',
+}
-- vim: syntax=luaRun Everything looks good except maybe:
To sum up: in my installation the patchset seems to work as expected. |
|
As Yarosval observed, the problem that is workarounded by the 'Fix concatenate with a nil value when give a warn' patch is already fixed in upstream ( luarocks@daf7e7e ) in more general way. We discussed it and decided to proceed now with our workaround and remove it when we'll prepare update to the new luarocks version. |
|
Re 'strange string.match behaviour': We debugged it with Yaroslav. It was due to interpreting |
|
I've run some tests on static layout (tarantool is built statically, installed in home directory).
GCC issued a warning: We decided to fix it later here: https://github.com/tarantool/tarantool/blob/master/extra/txt2c.c
|
|
rosik
approved these changes
Jun 16, 2019
Totktonada
approved these changes
Jun 16, 2019
There was a problem hiding this comment.
It seems the patchset handles all needs of the standard tarantool layout (when it is installed from a package manager). Portable layout or using tarantoolctl rocks directly from a build directory can lead to a warning re unability to find a Lua interpreter (it is not an error). We will handle it later I think.
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.