1 |
On 2020-09-03 15:37, Marek Szuba wrote: |
2 |
|
3 |
For the record, some mostly-cosmetic issues that have already been |
4 |
identified. Will include them in the next revision: |
5 |
|
6 |
> +if [[ ! ${_LUA_R0} ]]; then |
7 |
> + |
8 |
> +inherit multibuild toolchain-funcs |
9 |
> + |
10 |
> +BDEPEND="virtual/pkgconfig" |
11 |
|
12 |
There should be no BDEPEND in the eclass any more, it's a leftover from |
13 |
an earlier iteration which retrieved module directories in less |
14 |
conditional fashion. |
15 |
|
16 |
> +# Please note that you can also use bash brace expansion if you like: |
17 |
> +# @CODE |
18 |
> +# LUA_COMPAT=( lua5_{1..3} ) |
19 |
|
20 |
s/_/-/ |
21 |
|
22 |
> + eerror "No Lua implementation selected for the build. Please add one" |
23 |
> + eerror "of the following values to your LUA_TARGETS (in make.conf):" |
24 |
|
25 |
Will add "or package.use" here. |
26 |
|
27 |
> +# @FUNCTION: _lua_wrapper_setup |
28 |
> +# @USAGE: [<path> [<impl>]] |
29 |
> +# @INTERNAL |
30 |
> +# @DESCRIPTION: |
31 |
> +# Create proper 'lua' executable and pkg-config wrappers |
32 |
|
33 |
Should be "proper Lua executables" - for dev-lang/lua we have got both |
34 |
'lua' and 'luac', and for dev-lang/luajit we'll probably have 'luajit' |
35 |
(have yet to see if invoking 'luajit' as 'lua' works). |
36 |
|
37 |
> +# Check LUA_COMPAT for well-formedness and validity, then set |
38 |
> +# two global variables: |
39 |
> +# |
40 |
> +# - _LUA_SUPPORTED_IMPLS containing valid implementations supported |
41 |
> +# by the ebuild (LUA_COMPAT - dead implementations), |
42 |
|
43 |
Just say "minus" here, as it stands it is a bit confusing (at least to |
44 |
me) because my first reaction is to read the - as a dash, not as an |
45 |
arithmetic minus. |
46 |
|
47 |
-- |
48 |
MS |