On Wed, Nov 15, 2017 at 3:42 PM, Grant Edwards
<grant.b.edwa...@gmail.com> wrote:
> On 2017-11-15, R0b0t1 <r03...@gmail.com> wrote:
>> Apologies for the double post,
>>
>> On Wed, Nov 15, 2017 at 9:41 AM, R0b0t1 <r03...@gmail.com> wrote:
>>> On Wed, Nov 15, 2017 at 1:22 AM, Jorge Almeida <jjalme...@gmail.com> wrote:
>>>> On Tue, Nov 14, 2017 at 8:42 PM, R0b0t1 <r03...@gmail.com> wrote:
>>>>> What I am wondering about is if C code which uses
>>>>> __attribute__((optimize(...))) is against Gentoo package standards and
>>>>> would have to be removed from the Portage tree.
>>>>>
>>>>
>>>>
>>>> You can set your optimization preferences in make.conf, and still an
>>>> ebuild will override them if deemed unsafe. What would be the
>>>> difference?
>>>>
>>>
>>> Ebuilds are not supposed to do this, so if you file a bug report
>>> citing that ebuild changes will be made (eventually?) to work around
>>> it.
>>>
>>>
>>> On Wed, Nov 15, 2017 at 9:28 AM, Grant Edwards
>>> <grant.b.edwa...@gmail.com> wrote:
>>>> On 2017-11-15, R0b0t1 <r03...@gmail.com> wrote:
>>>>
>>>>> What I am wondering about is if C code which uses
>>>>> __attribute__((optimize(...))) is against Gentoo package standards and
>>>>> would have to be removed from the Portage tree.
>>>>
>>>> Huh?
>>>>
>>>> Gentoo enforces standards for the source code of packages?
>>>>
>>>> "They" review the source code for the Linux kernel, Gnome, KDE, Qt,
>>>> Chrome, Firefox, GCC, and 24670 thousand other packages and make sure
>>>> they all follow Gentoo coding standards?
>>>>
>>>
>>> To be consistent they would have to. Why I bring it up is that a
>>> number of optimizations in eix were removed due to the logic I gave
>>> above, despite there being no way to enable them without setting "-O3"
>>> globally.
>>>
>>> Cheers,
>>> R0b0t1
>>
>> https://bugs.gentoo.org/632315
>
> I don't see how that's relevent. That bug is about use flags and
> ebuild stuff, not about the C code inside a package's source files.
>
Right, but the reason that it is not allowed in ebuilds (or at least
in eix's case) was some sense of purism - despite the optimizations
being behind a useflag at the package level, someone determined this
was improper.
Applying this logic consistently, any package which uses the
"optimize" GCC attribute would be unsuitable for the main portage
tree.
If this doesn't make sense, that is exactly my point. Sorry for going
off on a tangent, I didn't expect any follow-up posts on it.
Cheers,
R0b0t1
