Gentoo Archives: gentoo-dev

From: hasufell <hasufell@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] rfc: calling all eclass phase functions by default
Date: Mon, 18 Aug 2014 12:30:53
In Reply to: Re: [gentoo-dev] rfc: calling all eclass phase functions by default by Sergey Popov
1 Sergey Popov:
2 > 18.08.2014 16:04, hasufell пишет:
3 >>> You have my strong opposition on such change as well. It will turn
4 >>> ebuilds into unreadable and undpredictable mess, please do not do that
5 >>>
6 >>
7 >> They are already fairly unreadable and unpredictable.
8 >>
9 >
10 > For you - maybe. But not for me.
11 >
12 > I am NOT talking about hacks like putting additional *.as files through
13 > echo(hello Boost ebuild) or doing something crazy with subshells.
14 >
15 > But most of the eclass and ebuilds are readable quite simple if you read
16 > devmanual, PMS and have a brain.
17 >
18 > Of course, there are sometimes non-trivial stuff that is hard to read.
19 >
20 > But majority of ebuilds and eclasses are fine to understand and predict.
21 >
22 > So, without examples from you, this discussion will lead to nowhere, so,
23 > please let's stop it.
24 >
26 From my time as a sunrise dev I strongly disagree. People have problems
27 with understanding the mess, including actual programmers. They have
28 enough technical understanding, but not the time or motivation to go
29 through all those funny pitfalls which are NOT properly documented in
30 devmanual.
32 The most popular example is what we are talking about right now:
33 indirect inheritance for example via games.eclass which inherits
34 base.eclass but does not export src_unpack so stuff like unpacker.eclass
35 and git-2.eclass will likely just do nothing if you inherit them before
36 games.eclass (which is required by games herd policy)... uhm. I doubt
37 you would have guessed this one if you saw the plain ebuild. I know the
38 pitfall, so I see it just from looking at the inherit line. But it is
39 far from being obvious.