Preprocessing options use non-standard naming conventions

Bug #1714252 reported by Yann Pouillon
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
libGridXC
New
High
Yann Pouillon

Bug Description

The preprocessing options used in LibGridXC follow non-standard naming conventions that may lead to name clashes in some cases, while some uses may be improper and/or obsolete.

The options in version 0.7.3 are the following: DEBUG_XC, GRID_SP, LIBXC, MPI, OLD_CRAY, __TEST__MODULE__ALLOC__.

This can be solved by:
  - renaming LIBXC to HAVE_LIBXC;
  - renaming MPI to HAVE_MPI;
  - possibly getting rid of the OLD_CRAY option;
  - refactor the __TEST__MODULE__ALLOC__ feature to have it handled as a test by the build system.

Part of this issue will be fixed at the same time as bug #1714246.

Revision history for this message
Yann Pouillon (pouillon) wrote :

A few words to clarify the proposed refactoring.

The undocumented __TEST__MODULE__ALLOC__ CPP option is associated to the optional compilation of a test program located in the src/alloc.F90 source file. This practice is strongly discouraged, because:

  - it hides tests which may be of importance deeply into the source code;
  - it allows parts of the source to be kept unmaintained for long periods of times.

The recommended practice is instead to provide the test program in a separate file and control its compilation from a Makefile, in addition to briefly documenting its purpose.

Changed in libgridxc:
importance: Undecided → High
assignee: nobody → Yann Pouillon (pouillon)
milestone: none → 0.9
Revision history for this message
Alberto Garcia (albertog) wrote :

My goal with the 'preprocess-to-enable' test in alloc.F90 was to have a self-contained file that could be shipped around without turning it into a new library. Note that it has no other dependencies.

Can you leave as it is but include a test in your build system to exercise the self-contained code?

Revision history for this message
Alberto Garcia (albertog) wrote :

In Siesta we are currently using the convention (for new features) to have preprocessor names of the form SIESTA__XXXXX.
Nick suggested it to avoid possible clashes when a cascade of programs and libraries is compiled. I guess that you have this under control.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related blueprints

Remote bug watches

Bug watches keep track of this bug in other bug trackers.