Re: [E-devel] E SVN: raster trunk/eina/src/lib

[Carsten H. (T. R. <ra...@ra...>]

On Tue, 14 Dec 2010 08:35:49 +1100 Brett Nash <na...@na...> said:

> > >
> > > I don't understand why raster is so reluctant in having them. Especially
> > > if we enable them only during a development cycle, and not in a release.
> > 
> > Indeed... several projects I work with enable tons of -W when
> > configured with --enable-maintainer-mode (even -Werror). I don't see a
> > point against doing this.
> 
> There are a few points.  First if you are on a different arch to the
> maintainers suddenly you can find yourself in warning hell.  Similarly
> different compiler versions have the same effect[1].
> 
> -Werror is even worse for this (especially when you are adding a new
> feature and you know what/why a warning is but you don't want to fix it
> for some reason).  As a person who always uses a 64bit machine + more
> warnings the most, adding a -Werror is a nightmare for me.
> 
> Third reason is it messes with peoples existing warning flags.  For
> instance I use[2][3]:
> 	-Wall -Wextra -Wno-sign-compare -Wno-unused-parameter
> A -Wall at the end resets my other flags, which is really annoying.
> 
> However the main problem is the simple philosophical one.  Don't tell
> people how to code.  Don't tell them what editor, don't tell them what
> compiler, don't tell them what architecture to use, don't tell them what
> C flags.
> 
> Having said that: People with no CFLAGS should probably be given a
> default set, and suggestions of CFLAGS to use is a good idea.

agreed. if you are an efl developer - you should PROBABLY have a set of warning
flags on by default during development (unless as you say - you are doing
something new and are not interested in fixing every little thing now, just
trying to bootstrap it and get it up at all). i don't understand when everyone
is obsessed by making it either default OR a --enable-warnings option when it
is simpler and easier to just set CFLAGS. if you have to tell someone of a
configure option and how to use it - you also have to spend the same effort to
tell them of how to set CFLAGS - and they make the the same effort (actually
less as they just set their cflags in 1 place for all their builds, but a
--enable option has to be passed every time they autogen/configure so cflags is
in fact a much better solution). the only thing that makes sense is having them
always on in all projects by default. but then as brett says - it messes with
existing warning flags in CFLAGS which is where they should go etc. etc. etc.

> 	Regards,
> 	nash
> 
> 
> 
> [1] I  was the first in my company to upgrade to gcc 4 at the time with
> 'mandatory' CFLAGS, and found myself in hundreds of warnings when the
> previous version was warning free.
> 
> [2] I'll probably be adding void arithmetic to this soon. 
> 
> [3] I used to have more.  I turned some off due to too many warnings
> elsewhere.
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ra...@ra...