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 |
> |
25 |
|
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. |
31 |
|
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. |