[CP2K:508] Re: cp2k release goals

[Teodoro Laino]

Hi Axel, Hi All,

with a today commit we have the necessary platform for specifying  
things in cp2k as
ready to be released or still in a development version.
Each section/keyword of the input has an additional marker  
(supported_feature), by default
set to .FALSE. and in case that section/keyword is considered  
sufficiently tested to be released
it can be set to .TRUE. in the source.

CP2K can now be compiled with a prepocessor flag: -D__RELEASE_VERSION.
Whenever producing a release version and one tried to access keywords/ 
sections not upgraded
as being supported_features cp2k stops with an error message.
I also introduced, as you suggested Axel, the  
"ENABLE_UNSUPPORTED_FEATURE" keyword in &GLOBAL.
In case it is specified and in case one runs a release version the  
program prints some warning messages
but the calculation continues exactly as for a development version.
For development version no check is performed whether a keyword is  
supported or not.

Now there's the fun part of the game: decide which keywords/sections  
can be considered supported.
I can do that  for part of the input (but only in my spare time, I  
did it only for few keywords to debug the
today commit).. If one wants to contribute please just send  me the  
proper patches for the keywords he analyzed.

The other thing to do is to provide for the platforms for which we  
want to support the release the proper
arch files with the extension .release (an arch file like sopt in  
which the -D__RELEASE_VERSION is added).
In this case one can compile the release just typing "make release"  
or something similar (I didn't add any arch file at the
moment)..

The next thing to do is to mark with different color supported/non- 
supported keyword on the on-line reference manual (still
didn't do that).

Cheers,
Teo

On 5 Jan 2008, at 22:31, Axel wrote:

> as written before, the most important decision would be to
> identify features, that should be labeled as supported. i would
> recommend to not remove anything from the release version, but
> rather add a flag to check clear supported features. the input could
> have a keyword (in &GLOBAL) ENABLE_UNSUPPORTED_FEATURES which
> would be set to false by default in releases and true in developement
> versions. that would make maintenance easier and every developer of
> a subsystem can decide on a fine grained level whether a feature
> is production ready or not.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cp2k.org/archives/cp2k-user/attachments/20080107/d618dc65/attachment.htm>