On 05/29/2015 01:02 PM, Ulrich Windl wrote:
>>>> Christian Seiler <[email protected]> schrieb am 29.05.2015 um 12:43 in
> Nachricht <[email protected]>:
>> - Sometimes you need to debug something and disable optimization for
>> that. Then you might need want to rebuild a package with a different
>> -O level than the package typically has. Of course, one can
>> tediously look at the means that different software provides to do
>> so (if at all) - or one can just assume that setting CFLAGS="-O0"
>> before running configure / make will do the trick.
>
> Yes, but someone could also define `CC="gcc -O0"' and it might work.
> My proposal was mostly _against_ such misusing of flags.
Ok, CC="gcc -O0" is definitely misuse, because some build systems will
assume that CC contains the compiler directly (without options), which
will break them.
But why do you consider setting CFLAGS="-O0" to be misuse? I consider
that possibility to be a feature, not a bug. (And according to the way
most build systems are structured, I'm not alone in that.)
> Also, you cannot easily _add_ flags to the existing set of flags.
I really don't get what you mean here. Who should add flags to what
existing set?
>> - There is a goal to harden as much software as possible in Debian, so
>> there's a recommendation that things like -fstack-protector-strong
>> are to be used (unless the software doesn't work otherwise).
>
> IMHO this is useful for the developer to fix his/her bugs, but for
> production systems it will just make software bigger and slower.
I disagree here vehemently that it's only useful for development (in
fact, I would assert that it's rather useless for development and only
really useful in production), but this would go off a tangent, so I'll
leave it at that.
For the purposes of the discussion here let me just say that Debian
also activates other measures as well, some of those with a completely
negligible performance impact. Thus the original point I was trying to
make, namely that there are legitimate use cases for modifying build
flags by default, still stands.
>> (Of course, checking that the compiler supports your flag is always
>> better, there is a macro for that; and things like pthread actually
>> have a standardized macro that do that automatically.)
>> Alternatively, you can set it directly in Makefile.am via
>> AM_CFLAGS = -additional-flags
>> which will automatically be added to the list of flags.
>
> With all these solutions we have the problem that the user who
> compile (configres) the software has to be kind of an expert to know
> al the flags and syntaxes. You probably are such an expert. I don't
> know all of these.
What's your point here? That people could set flags that they shouldn't
set? Sure. I'm not saying people SHOULD override the compiler flags
externally if they don't know what they're doing, I'm just saying that
people who do know what they're doing should be able to do so.
> I also hope you got what I tried to say.
No, sorry, I really have no idea where you're coming from, at least
from a big picture kind of perspective. The reason I sent the original
patch is, in a nutshell:
- there are legitimate use cases for overriding flags externally
- there's a standard way of doing so that the vast majority of
projects follow
=> thus the patch updates the build system to support that method,
because it will make life easier for people
Nothing more, nothing less.
What exactly do you want to achieve? And why?
And perhaps more importantly, that's not clear to me at all after
re-reading your emails: do you object to my patch? Or are you just
throwing general ideas around?
Regards,
Christian
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
