Re: [gentoo-dev] [PATCH] lua.eclass: initial implementation

[Marek Szuba]

On 2020-09-06 17:46, David Seifert wrote:

> Unfortunately we won't get around a single-r1-style eclass too. What
> about all those programs embedding a specific lua version as plugin
> architecture?

This is still very much on my to-do list, I simply figured it would make
it easier for everyone reviewing this to leave it until the next iteration.

> But the basic principles underlying your eclass
> are finally correct, unlike the previous lua.eclass attempt.

Thank you! Of course it would have been much more difficult to achieve
were it not for Michał's work on python-r1.


On 2020-09-06 19:13, Azamat Hackimov wrote:

>> +# @ECLASS-VARIABLE: LUA
>> +# @DEFAULT_UNSET
>> +# @DESCRIPTION:
>> +# The absolute path to the current Lua interpreter. This variable is set
>> +# automatically in functions called by lua_foreach_impl().
>> +#
>> +# Example value:
>> +# @CODE
>> +# /usr/bin/lua5.1
>
> I think there also needs a LUAC variable that points to the current
> Lua compiler.

Possibly, then again I have begun to wonder if we even need LUA
itself... Moreover, there would be no LUAC were the eclass made to
support luajit.

I guess we'll see how many ebuilds actually need these once we have
begun porting them to lua.eclass.

> There needs a LUA_MAJOR_VERSION (V variable in lua.pc, i.e. 5.1, 5.2,
> 5.3) instead of full version (R variable in lua.pc, i.e 5.1.5, 5.2.4).
> Some obscure Lua packages are required to define V variable to work
> properly.

Nah, one can easily go from the full version to the ABI version
(<nitpick>LUA_MAJOR_VERSION would just be 5</nitpick) in an ebuild by
either removing the "lua" prefix from ELUA or using ver_cut on the
output of $(lua_get_version). I would rather have the eclass output more
information that the user can partly discard, than output less
information and run into problems with that one braindead package which
insists of being passed the full Lua version.

-- 
MS