This is a mixture of changes, I couldn't easily separate them. Addresses #197. The changes are:
1) Detect shumlib at the top of the tree. It is needed in different subdirectories. The problem is that compilers behave differently with modules that are used transitively, i.e. procedure X uses module A which uses module B. Without this change src/opsinputs/opsinputs_cxwriter_mod.F90 fails to compile because it cannot find a shumlib module. This file doesn't reference shumlib but it does use modules that use shumlib.
2) There are various sections of the cmake files that set specific options for different compilers. I have added sections for NAG.
3) There are places CMAKE_Fortran_FLAGS is appended in ways that result in options appearing multiple times on the same command line. Some compilers tolerate this but nagfor does not.
4) Linking with nagfor results in problems due to the addition of linker flags that aren't compatible with nagfor's syntax. Linking with C++ is simpler. I have only done this for nagfor.
5) This include directories for the OPS directories were not actually being added, I have done that here (also for shumlib). The reason this doesn't matter for the other compilers is that they implicitly search the directory that the source file is contained it. nagfor doesn't however so the directories need to be added explicitly.
This is a mixture of changes, I couldn't easily separate them. Addresses #197. The changes are:
1) Detect shumlib at the top of the tree. It is needed in different subdirectories. The problem is that compilers behave differently with modules that are used transitively, i.e. procedure X uses module A which uses module B. Without this change src/opsinputs/opsinputs_cxwriter_mod.F90 fails to compile because it cannot find a shumlib module. This file doesn't reference shumlib but it does use modules that use shumlib.
2) There are various sections of the cmake files that set specific options for different compilers. I have added sections for NAG.
3) There are places CMAKE_Fortran_FLAGS is appended in ways that result in options appearing multiple times on the same command line. Some compilers tolerate this but nagfor does not.
4) Linking with nagfor results in problems due to the addition of linker flags that aren't compatible with nagfor's syntax. Linking with C++ is simpler. I have only done this for nagfor.
5) This include directories for the OPS directories were not actually being added, I have done that here (also for shumlib). The reason this doesn't matter for the other compilers is that they implicitly search the directory that the source file is contained it. nagfor doesn't however so the directories need to be added explicitly.