1 |
On Wed, Nov 15, 2017 at 3:42 PM, Grant Edwards |
2 |
<grant.b.edwards@×××××.com> wrote: |
3 |
> On 2017-11-15, R0b0t1 <r030t1@×××××.com> wrote: |
4 |
>> Apologies for the double post, |
5 |
>> |
6 |
>> On Wed, Nov 15, 2017 at 9:41 AM, R0b0t1 <r030t1@×××××.com> wrote: |
7 |
>>> On Wed, Nov 15, 2017 at 1:22 AM, Jorge Almeida <jjalmeida@×××××.com> wrote: |
8 |
>>>> On Tue, Nov 14, 2017 at 8:42 PM, R0b0t1 <r030t1@×××××.com> wrote: |
9 |
>>>>> What I am wondering about is if C code which uses |
10 |
>>>>> __attribute__((optimize(...))) is against Gentoo package standards and |
11 |
>>>>> would have to be removed from the Portage tree. |
12 |
>>>>> |
13 |
>>>> |
14 |
>>>> |
15 |
>>>> You can set your optimization preferences in make.conf, and still an |
16 |
>>>> ebuild will override them if deemed unsafe. What would be the |
17 |
>>>> difference? |
18 |
>>>> |
19 |
>>> |
20 |
>>> Ebuilds are not supposed to do this, so if you file a bug report |
21 |
>>> citing that ebuild changes will be made (eventually?) to work around |
22 |
>>> it. |
23 |
>>> |
24 |
>>> |
25 |
>>> On Wed, Nov 15, 2017 at 9:28 AM, Grant Edwards |
26 |
>>> <grant.b.edwards@×××××.com> wrote: |
27 |
>>>> On 2017-11-15, R0b0t1 <r030t1@×××××.com> wrote: |
28 |
>>>> |
29 |
>>>>> What I am wondering about is if C code which uses |
30 |
>>>>> __attribute__((optimize(...))) is against Gentoo package standards and |
31 |
>>>>> would have to be removed from the Portage tree. |
32 |
>>>> |
33 |
>>>> Huh? |
34 |
>>>> |
35 |
>>>> Gentoo enforces standards for the source code of packages? |
36 |
>>>> |
37 |
>>>> "They" review the source code for the Linux kernel, Gnome, KDE, Qt, |
38 |
>>>> Chrome, Firefox, GCC, and 24670 thousand other packages and make sure |
39 |
>>>> they all follow Gentoo coding standards? |
40 |
>>>> |
41 |
>>> |
42 |
>>> To be consistent they would have to. Why I bring it up is that a |
43 |
>>> number of optimizations in eix were removed due to the logic I gave |
44 |
>>> above, despite there being no way to enable them without setting "-O3" |
45 |
>>> globally. |
46 |
>>> |
47 |
>>> Cheers, |
48 |
>>> R0b0t1 |
49 |
>> |
50 |
>> https://bugs.gentoo.org/632315 |
51 |
> |
52 |
> I don't see how that's relevent. That bug is about use flags and |
53 |
> ebuild stuff, not about the C code inside a package's source files. |
54 |
> |
55 |
|
56 |
Right, but the reason that it is not allowed in ebuilds (or at least |
57 |
in eix's case) was some sense of purism - despite the optimizations |
58 |
being behind a useflag at the package level, someone determined this |
59 |
was improper. |
60 |
|
61 |
Applying this logic consistently, any package which uses the |
62 |
"optimize" GCC attribute would be unsuitable for the main portage |
63 |
tree. |
64 |
|
65 |
If this doesn't make sense, that is exactly my point. Sorry for going |
66 |
off on a tangent, I didn't expect any follow-up posts on it. |
67 |
|
68 |
Cheers, |
69 |
R0b0t1 |