I think I wasn't clear.
I started doing things in LO when things were a lot harder than they
are now. I'm glad for all the community members who have been putting
order in this chaos. That experience lead me to believe that the policy
should be "make it easy for the n00b".
When I tried using this flag, I ended up not being able to _build_ at
all. And that wasn't even due to my own mistake, only some module I
know nothing at all is breaking the build. The best advice I got on IRC
was to disable the flag!
And that was 1-2 months back, max.
My point is that building for a n00b should be very simple. And we can
put that flag in the module-specific make file with the right switch.
make -r is building, make -sr is building and running the unit testing,
make -er would be building with all the restrictive flags.
Something like that...
What do you think?
Marc-André Laverdière
Software Security Scientist
Innovation Labs, Tata Consultancy Services
Hyderabad, India
On Tue 27 Sep 2011 12:42:48 AM IST, Stephan Bergmann wrote:
> On 09/26/2011 01:15 PM, Marc-André Laverdière wrote:
>> I tried doing that, but it seems that my autogen flags made it so that I
>> was compiling some module unknown to me that was in 'build warning
>> land'.
>>>> Unless we don't have modules living in such countries anymore, I won't
>> want to enable that option.
>>>> I see this flag as an aspirational goal "let us fix all that stuff so
>> that we can -one day- compile everything that way"
>> We were there already, and I think we still are there (at least on
> Linux with recent GCC, maybe it decayed on Windows).
>>> I personally am against anything that makes it harder for a n00b like me
>> to get something done. The learning curve is not-so-easy so lets not
>> make it worse.
>> For just compiling the sources, the default of --disable-werror is
> hence the way to go. For actually making changes to the code, and
> especially doing so as a newbie -- what's wrong with the help offered
> by those compiler warnings? (Given they are caused by your changes,
> not by code that was already dirty with warnings before you touched it
> -- which brings me back to the point that all developers should use
> --enable-werror all the time, to keep the master clean.)
>> -Stephan
>