Pollution of CPP #define namespace

[goddard-fortran-ecosystem]

Pollution of CPP #define namespace

[tclune]

@citibeth The conflict in the CPP token is unfortunate. With a serial build you should indeed not be setting it when compiling driver.F90. Because the compilation of driver.F90 is in user space, you ought to be able to control what flags are sent to it. I could add a new token along the lines you suggest, but to delete the other one would break every one else's build that does use MPI

Perhaps you could just create and maintain a copy of driver.F90 in your own source tree? It really won't be changing until 4.0 is out in which case this issue will hopefully evaporate.

I'm open to any suggestion for the current version that does not break the builds of others.

[citibeth]

@tom Clune <[email protected]> Is there documentation on how this flag is supposed to work?

…

On Tue, Dec 4, 2018 at 9:30 AM Tom Clune ***@***.***> wrote: @citibeth <https://github.com/citibeth> The conflict in the CPP token is unfortunate. With a serial build you should indeed not be setting it when compiling driver.F90. Because the compilation of driver.F90 is in user space, you ought to be able to control what flags are sent to it. I could add a new token along the lines you suggest, but to delete the other one would break every one else's build that does use MPI Perhaps you could just create and maintain a copy of driver.F90 in your own source tree? It really won't be changing until 4.0 is out in which case this issue will hopefully evaporate. I'm open to any suggestion for the current version that does not break the builds of others. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#40 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB1cd6iHHV_64fDWrx1lrm_OBeTd1Ma6ks5u1ocMgaJpZM4Y_sFa> .

[tclune]

Apparently not. :-(

There really is not much to it though.

First, within the build of the library itself the flag is used to export the MPI specific extensions of pFUnit in pFUnit_mod and whether or not pFUnit's init/finalize trigger MPI's init/finalize. Of course in this context the CPP token is controlled by the build process, not by the user.

Then in driver.F90 it is used to (a) include 'mpif.h' (which may not even be necessary any more) and (b) to have the runner use an MpiContext for controlling resources available to the test runner. The default is a serial context.

Basically if you build the library with -DMPI=YES then you should compile the driver with -DUSE_MPI, and otherwise you should not. Previously there were two separate drivers, which avoided this issue, but resulted in significant code duplication. In 4.0 the duplicated code will have been refactored into the framework, leaving the driver as a very simple entity. The MPI logic is compiled into a separate library , and MPI is enabled by the user by linking with"-lpfunit -lfunit", while a serial test suite is compiled by linking with just "-lfunit". (At least I think this will work - I've only done a small bit of testing thus far.)

[tclune]

It may also be worth pointing out that, so long as you have MPI in your environment anyway, then it is perfectly sensible to use a parallel build of pFUnit for serial tests. Depending on the flavor of MPI you may need to launch the test with mpirun -np 1 ... , but many flavors allow a 1 PE launch without mpirun.