1 |
On Thu, 2020-09-03 at 15:37 +0200, Marek Szuba wrote: |
2 |
> Ladies and gentlemen, |
3 |
> |
4 |
> Here is my first attempt on creating an eclass which would handle |
5 |
> installation of Lua modules for multiple implementations. As some of |
6 |
> you |
7 |
> are aware of, the lack of such an eclass has been a major issue for |
8 |
> our |
9 |
> efforts on slotting dev-lang/lua. |
10 |
> |
11 |
> With many, many thanks to mgorny and everyone else who has worked on |
12 |
> python-r1.eclass, to whom lua.eclass bears, ahem, striking |
13 |
> resemblance. |
14 |
> |
15 |
> At the moment this is only really useful for installing Lua modules |
16 |
> but |
17 |
> assuming it doesn't turn out to be a total failure, I'll work on |
18 |
> single-target support as the next step. We should probably think about |
19 |
> adding LuaJIT support at some point too. |
20 |
> |
21 |
> Comments are very much welcome! |
22 |
|
23 |
This is finally going in the right direction. Unfortunately we won't get |
24 |
around a single-r1-style eclass too. What about all those programs |
25 |
embedding a specific lua version as plugin architecture? Conversely, we |
26 |
also won't get around the multi eclass too, given how many upstreams |
27 |
won't unbundle/port their lua dependencies and require access to pure- |
28 |
lua packages. But the basic principles underlying your eclass are |
29 |
finally correct, unlike the previous lua.eclass attempt. |