[torquedev] Release Candidate for TORQUE 2.5.8

Ken Nielson knielson at adaptivecomputing.com
Wed Aug 24 06:08:19 MDT 2011

----- Original Message -----
> From: "Michael Jennings" <mej at lbl.gov>
> To: torquedev at supercluster.org
> Sent: Tuesday, August 23, 2011 12:04:11 PM
> Subject: Re: [torquedev] Release Candidate for TORQUE 2.5.8
> On Tuesday, 23 August 2011, at 06:47:51 (-0400),
> Glen Beane wrote:
> > You make some good points. I hope all developers use
> > --enable-gcc-warnings (it looks like some warnings did slip through
> > though). It is also helpful to have people out in the community
> > reporting warnings back to the developers.
> I agree. It would be good for the Adaptive folks and other
> contributors to build with warnings so that potential missteps can be
> corrected early. But it's important to keep in mind that gcc's
> warning settings (defaults, groupings, and available options) change
> with every release, and code that built warning-free in a previous
> version will often have warnings (and sometimes even errors!) in newer
> versions. So we should endeavour to quantify expectations and targets
> (and be realistic about the fact that "no warnings" is very much a
> moving target). :-)
> Michael

Following is the reason we disabled gcc-warnings as a defeault to the TORQUE build. When the patch was submitted the reasoning came with it. I just did not move the knowledge to the permanent memory of my brain.

In order to default to using -Werror with gcc you must explicitly override all existing CFLAGS. If a user already has the default CFLAGS setting for example of "-00 -g3 -W -Wall -Wmissing-prototypes -Wmissing-declarations" then they cannot build TORQUE without specifying --disable-gcc-warnings. "make distcheck" also fails unless the same flag is added to DISTCHECK_CONFIGURE_FLAGS. It seems more convenient to the end user to be able to build without gcc-warnings rather than error out on something most likely benign.

It is up to us as developers to make sure we develop with the gcc-warnings enabled. We also plan to start using clang and llvm. (It isn't pretty)



More information about the torquedev mailing list