Re: [AMBER-Developers] Dealing with compiler warnings, etc.

From: case <case.biomaps.rutgers.edu>
Date: Wed, 6 Apr 2011 22:57:56 -0400

On Wed, Apr 06, 2011, MengJuei Hsieh wrote:
>
> Yeah, I sort of went through some parts of LEaP once or twice before. I am
> always amazed by the attempts to do C++ ways of thinking without using
> C++..., but I digress. Please check out the remove-warnings branch if you
> are interested.

It's worth remembering that LEaP was written before there was any stable C++.
Early C++ compilers were extremely non-portable, and a great many of the
features you now associate with C++ were not available.

>
> There should be fewer warnings now, but I did leave some scary design issues
> and yacc parts untouched. I am no yacc expert, what's the best way to do it:
> modifying the *.y or committing both *.y and *.c products?

The .y files are the true source, but I really wonder if there is anything to
be gained by (trying) to remove warnings from the code generated, which will
be different depending on whether yacc, byacc or bison is used...

I'm also a little concerned about how people plan to eventually merge the
remove-warnings branch back into the master. For code that hasn't changed
in 20 years, and/or which we didn't write in the first place (Xraw, Wc, etc.)
the merge should be easy. But for active code that is constantly being
changed, I worry about merges. The general rule would be to merge often,
so that glitches are quickly caught, and maybe soon would be a good time to
start that.

[I'm pleased that most of the branches I follow, such as rism-dev, pbsa-dev,
etc. are regularly merged with the master. If you are keeping a branch that
doesn't do that, consider whether or not you are being wise.]

...dac


_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Apr 06 2011 - 20:00:03 PDT
Custom Search