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
signature.asc
Description: OpenPGP digital signature
