Re: [gentoo-dev] [PATCH] lua.eclass: initial implementation
Marek, Is there any plans how to begin migrating lua packages to new eclass? As I can see, the current stable dev-lang/lua:0 package is not suited for it, while other slotted packages have major flaws about *.pc handling. вт, 8 сент. 2020 г. в 17:32, Marek Szuba : > > Merged, thank you everyone who has weighed in with their comments both > on IRC and here. > > -- > MS > -- >From Siberia with Love!
Re: [gentoo-dev] [PATCH] lua.eclass: initial implementation
Merged, thank you everyone who has weighed in with their comments both on IRC and here. -- MS signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] lua.eclass: initial implementation
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 (LUA_MAJOR_VERSION would just be 5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] lua.eclass: initial implementation
On Thu, 2020-09-03 at 15:37 +0200, Marek Szuba wrote: > Ladies and gentlemen, > > Here is my first attempt on creating an eclass which would handle > installation of Lua modules for multiple implementations. As some of > you > are aware of, the lack of such an eclass has been a major issue for > our > efforts on slotting dev-lang/lua. > > With many, many thanks to mgorny and everyone else who has worked on > python-r1.eclass, to whom lua.eclass bears, ahem, striking > resemblance. > > At the moment this is only really useful for installing Lua modules > but > assuming it doesn't turn out to be a total failure, I'll work on > single-target support as the next step. We should probably think about > adding LuaJIT support at some point too. > > Comments are very much welcome! This is finally going in the right direction. 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? Conversely, we also won't get around the multi eclass too, given how many upstreams won't unbundle/port their lua dependencies and require access to pure- lua packages. But the basic principles underlying your eclass are finally correct, unlike the previous lua.eclass attempt.
Re: [gentoo-dev] [PATCH] lua.eclass: initial implementation
On Thu, 3 Sep 2020 14:49:25 +0100 Michael 'veremitz' Everitt wrote: > I know this is a much more onerous "solution" but I thought I would throw > it out there, and see if any other interested parties (eg. kent\n and > potentially graaff) may be able to share their thoughts.. Actually, the more I think about it, there are 2 major reasons not to do this: 1. Its a premature abstraction that centralises a point of failure, and so any defects in this POF scale to all places, producing even more places where changing one eclass requires regenerating the md5 cache for the whole tree, and makes it *harder* to specify logic that only occurs in one languages ecosystem. 2. What happens if two eclasses inherit this shared eclass, and declares "which variables do I look into" via other variables that define its API?, and then, one ebuild consumes *both*. Presently, inheriting two eclasses, one for python, one for lua, and taping together how they build inside the ebuild itself seems viable. But if the logic is shoehorned into a common eclass, that will likely go really fucking pear shaped, unless done with a very fucked up/complicated API. I don't think this is worth it. pgpDDuuC_8O8A.pgp Description: OpenPGP digital signature
[gentoo-dev] [PATCH] lua.eclass: initial implementation
Ladies and gentlemen, Here is my first attempt on creating an eclass which would handle installation of Lua modules for multiple implementations. As some of you are aware of, the lack of such an eclass has been a major issue for our efforts on slotting dev-lang/lua. With many, many thanks to mgorny and everyone else who has worked on python-r1.eclass, to whom lua.eclass bears, ahem, striking resemblance. At the moment this is only really useful for installing Lua modules but assuming it doesn't turn out to be a total failure, I'll work on single-target support as the next step. We should probably think about adding LuaJIT support at some point too. Comments are very much welcome!
