1 |
Denis Dupeyron wrote: |
2 |
|
3 |
> Correct me if I'm wrong, but this has nothing to do with being |
4 |
> interactive or not. To me, an ebuild that dies (intentionally or due |
5 |
> to a build error) isn't interactive at all. |
6 |
|
7 |
Their phrase, not mine. ;) I think the idea is you should be able to emerge -e |
8 |
world and walk away and not have anything interrupt the process thus requiring |
9 |
the user interact with the system. I'm personally for dying as soon as |
10 |
possible, like before the actual compiling starts, but I don't think that's |
11 |
possible yet. |
12 |
|
13 |
> If a package is known not to work with a certain flag, being able to |
14 |
> emerge it won't change the fact that it doesn't run. |
15 |
|
16 |
If a package is known to not work with a certain flag it should be filtered so |
17 |
it does run. |
18 |
|
19 |
> Plus, if the |
20 |
> solution is considered good for python, I don't understand why it |
21 |
> wouldn't be good for any other package. Are you saying that Paul's |
22 |
> proposition of having the python ebuild die on use of --fast-math |
23 |
> isn't good ? |
24 |
|
25 |
Yes. |
26 |
|
27 |
If yes, why ? And what is your better idea ? |
28 |
|
29 |
I prefer a filter-flags with a ewarn (or elog, haven't read that thread yet ;)) |
30 |
message. |
31 |
|
32 |
* The -ffast-math option is known to break this package and has been filtered |
33 |
from your CFLAGS. Link to Safe CFLAGS wiki page, blah blah blah. |
34 |
|
35 |
I like this better because it informs me of what I did wrong, what was done to |
36 |
correct it, and how I can correct it for myself in the future if I choose to. I |
37 |
don't like artificial barriers and things not working without immediate |
38 |
attention. Call me lazy but it's annoying when you know what you're doing yet |
39 |
you have to jump through hoops to get it done. |
40 |
|
41 |
> Which is exactly the reason why we could benefit of something that |
42 |
> enables us to manage this in a clean and safe way. I'm not saying I |
43 |
> have a candidate for that "something", but I wanted to discuss if |
44 |
> there was an interest in it. |
45 |
> |
46 |
> Let's take again the example of -ftracer which can be enabled by the |
47 |
> -fprofile-use meta-flag. Imagine we have a mechanism somewhere (again, |
48 |
> the reason I'm being vague is that my point isn't to discuss |
49 |
> implementation just yet) that adds -fno-tracer to CFLAGS. In this |
50 |
> case, you're covered wether -ftracer was added directly on indirectly |
51 |
> by fprofile-use, which actually simplifies the number of flags that |
52 |
> you need to blacklist. Thus ebuilds don't have to take care of it, |
53 |
> bugs don't pour into bugzie, and Jakub can avoid overheating. |
54 |
|
55 |
Do you mean for ebuilds that knowingly break with -ftracer, or for everything? |
56 |
There are packages that expect to be built with certain flags; not -ftracer, |
57 |
but others. Fex, libao needs -ffast-math ;). Also, what about ebuilds that do |
58 |
use -fprofile, like gcc itself? I know toolchain.eclass strips all flags, I'm |
59 |
just using it as an example. |
60 |
|
61 |
If you mean just for packages that break with certain flags then absolutely. |
62 |
But such a mechanism would have to be maintained for every different GCC |
63 |
version, since -fprofile might not invoke -ftracer in every version, and indeed |
64 |
some versions might not even recognize -fno-tracer and bail with an error. |
65 |
|
66 |
>> Users playing with CFLAGS get to keep the pieces. Trying to |
67 |
>> dummy-proof the |
68 |
>> system doesn't help anyone but the dummies. ;) |
69 |
> |
70 |
> I'm one of those devs who care for our users. I think it's dangerous |
71 |
> to try and categorize users in, for example, dummies and non-dummies, |
72 |
> as you say. Who are we to judge this or that user is a dummy ? Plus, |
73 |
> we all are the dummy of somebody else. |
74 |
|
75 |
Okay, bad joke aside, there are always going to be users who tweak GCC flags. |
76 |
This has to be expected, as they're mysterious, and technical, and kinda cool. |
77 |
I like the tweaker crowd and I am a dummy, so no offense was intended to either |
78 |
groups. I meant that if you safety-proof a complex system, people never learn |
79 |
that they're doing anything wrong in the first place. |
80 |
|
81 |
> Anyway, I was thinking more in terms of making the job of developers, |
82 |
> bug wranglers, and poor old bugzilla easier, cleaner, safer. How many |
83 |
> bugs do we have that are due to dangerous flags ? |
84 |
|
85 |
Mad props to the bug-wranglers, but I don't think it'll be a cakewalk to |
86 |
automate this in any sane way. |
87 |
|
88 |
> How much time and |
89 |
> effort could we save if we didn't have those ? Also, I was thinking |
90 |
> that if a good solution was found to deal with a dangerous flag in a |
91 |
> certain package, maybe it was a good idea to extend this solution to |
92 |
> other packages. And finally, if said solution becomes common, maybe |
93 |
> it's a good idea to make it system-wide with a possibility to override |
94 |
> the setting by the user or the ebuild. It seems we already have |
95 |
> per-package CFLAGS, so part of this, at least, is already implemented. |
96 |
|
97 |
Right, but how are people supposed to learn something is dangerous if all the |
98 |
sharp edges have been filed off? And how can you decide which flags are "bad" |
99 |
and "good" on a global level when for the most part compiler parameters are akin |
100 |
to black magic? |
101 |
|
102 |
I guess in the end it comes down to personal philosophies on how to handle this, |
103 |
and I'm not going to try to change anyone's opinions. I hope that when this |
104 |
does get implemented there's a relatively easy way to opt-out ;). |
105 |
|
106 |
--de. |