1 |
On Thu, 17 Dec 2020 14:38:43 -0600 |
2 |
William Hubbs <williamh@g.o> wrote: |
3 |
|
4 |
> On Sat, Dec 12, 2020 at 09:22:06PM -0500, Mike Gilbert wrote: |
5 |
|
6 |
> > I don't really understand what you mean by this. I am converting one |
7 |
> > internal bash function into an external script so that its python |
8 |
> > dependencies can be better defined and managed. |
9 |
> |
10 |
> What I mean is, ebuilds should not be calling _meson_env_array at all |
11 |
> since it is defined and documented as an eclass internal function. |
12 |
> |
13 |
> I would like to know more about what the gallium-nine-standalone ebuild |
14 |
> is doing and why it needs to call a meson.eclass internal function. |
15 |
> |
16 |
> On the other hand, if _meson_env_array is meant to be called by ebuilds, |
17 |
> we need to rename it and improve the documentation for it in the eclass. |
18 |
|
19 |
I knew I spoke to someone about this on IRC and turns out it was you 2 |
20 |
years ago. :P The ebuild needs to render flags as a Meson array and |
21 |
this eclass function is the best way to do it. You did not know why it |
22 |
was private and said to go ahead anyway but file a bug so that this |
23 |
situation could be improved. I admittedly didn't get around to filing a |
24 |
bug but I was totally prepared to deal with the fall out if it broke. |
25 |
Now floppym is improving the situation anyway and fixing the ebuild |
26 |
too. I give my thanks to him. Job done? |
27 |
|
28 |
-- |
29 |
James Le Cuirot (chewi) |
30 |
Gentoo Linux Developer |