Create generic template based on ncrc5-intel-oneapi.mk that works for GFDL's amd dev box#72
Create generic template based on ncrc5-intel-oneapi.mk that works for GFDL's amd dev box#72laurenchilutti wants to merge 4 commits into
Conversation
rem1776
left a comment
There was a problem hiding this comment.
The two changes I commented should make this generic enough to use on most linux systems, instead of just targetting the amd box with hardcoded paths. We could rename the template like linux-intel-oneapi.mk.
Co-authored-by: Ryan Mulhall <35538242+rem1776@users.noreply.github.com>
Co-authored-by: Ryan Mulhall <35538242+rem1776@users.noreply.github.com>
|
This is ready to go now! |
|
|
||
| # REPRO, DEBUG and TEST need to be mutually exclusive of each other. | ||
| # Make sure the user hasn't supplied two at the same time | ||
| ifdef REPRO |
There was a problem hiding this comment.
I realize this wasn't introduced in this template, but I feel since these are exclusive options, we should probably change this to something similar to what CMake uses: BUILD_TYPE. Then BUILD_TYPE can equal one of several opeions: REPRO, DEBUG, TEST, or PROD (although if not set BUILD_TYPE will default to PROD.
| # Required Preprocessor Macros: | ||
| CPPDEFS += -Duse_netCDF | ||
|
|
||
| # Additional Preprocessor Macros needed due to Autotools and CMake |
There was a problem hiding this comment.
Change the comment to indicate what this does, not because it was added in Autotools and CMake. It indicates the system libraries already have sched_getaffinity.
| # Macro for Fortran preprocessor | ||
| FPPFLAGS := -fpp -Wp,-w $(INCLUDES) | ||
| # Fortran Compiler flags for the NetCDF library | ||
| FPPFLAGS += $(shell nf-config --fflags) |
There was a problem hiding this comment.
Move all the netCDF options to one location.
| FFLAGS := -fno-alias -auto -safe-cray-ptr -ftz -assume byterecl -i4 $(REAL_PRECISION) -nowarn -traceback | ||
|
|
||
| # Set the ISA (vectorization) as user defined or based on the target | ||
| ifdef ISA |
There was a problem hiding this comment.
Why are we setting three different variables to the same value? I understand this is so it is easier to have different values for build type, but that adds complexity that I don't feel is needed. It also makes it more difficult to maintain.
| endif | ||
|
|
||
| # Flags based on perforance target (production (OPT), reproduction (REPRO), or debug (DEBUG) | ||
| FFLAGS_OPT = -O3 -debug minimal -fp-model source $(ISA_OPT) |
There was a problem hiding this comment.
Same thing about multiple variables with the build-type appended to the name. We should have a single section that checks the build-type, and then sets a single variable based on the options needed for that build type.
| FFLAGS_COVERAGE = -prof-gen=srcpos | ||
|
|
||
| # Macro for C preprocessor | ||
| CPPFLAGS := -D__IFC $(INCLUDES) |
There was a problem hiding this comment.
I realize that __IFC is for legacy Intel C. Is FMS, or any of the FMS-based components using this macro? If they are, we should update where that macro is to use it or one of the macros that the Intel OneAPI compiler will set (__INTEL_COMPILER or __INTEL_LLVM_COMPILER).
| CFLAGS_DEBUG = -O0 -g $(ISA_DEBUG) | ||
|
|
||
| # Flags to add additional build options | ||
| CFLAGS_OPENMP = -qopenmp |
There was a problem hiding this comment.
Similar to some of the other options, I think this should closer mimic CMake, we have the user set an OPENMP make macro to on or off, and then modify the CFLAGS and FCFLAGS directly.
Creating a new mk template for intel oneapi that is generic for linux. Allows for mkmf to work on the GFDL AMD development machine.