Autoconf-based build framework #1197
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This patch is a first draft of an autoconf-based build for MOM6.
This is a hybrid solution which relies on mkmf and list_paths to
automatically generate the model dependencies, but uses autoconf to
determine the necessary compiler flags for building the model.
Recommended instructions for testing the build system, as well as
instructions for new users, are shown below.
```
# (Optional) Fetch mkmf and build FMS
cd deps
make -j
cd ..
# Set up the autoconf build files
autoreconf
# Configure and build the model in /build
mkdir -p build
cd build
../configure
make -j
```
As with standard autoconf builds, compilers and flags can be configured
with prepended arguments, e.g.
```
FC=mpifort FCFLAGS="-g -O0 -Wall -Wextra" ./configure
make
```
Introduction of autoconf configuration should not interfere with any
existing mkmf-based build procedures.
A more detailed discussion is provided below.
----
At minimum, only the following instructions would be required:
```
autoreconf
./configure
make
```
but this requires that both mkmf and FMS be accessible in standard
searchable directories.
A more realistic MOM6-only build would be as shown below
```
autoreconf
PATH="path/to/mkmf/bin:${PATH}" \
FCFLAGS="-Ipath/to/fms_mods" \
LDFLAGS="-Lpath/to/fms_lib" \
./configure
make
```
where `path/to/xxx` points to the location of the pre-installed content.
To alleviate this issue, a Makefile in the `deps` directory has been
provided, which checks out copies of mkmf and FMS and places them in the
`deps` directory. If the MOM6 `./configure` script is unable to find
mkmf or FMS, then it will automatically continue to search inside of the
`deps` directory.
----
The `deps` directory provides templates for an autoconf build of FMS
resembling our MOM6 build.
The Makefile provides the following rules:
`make` or `make all`:
Fetch mkmf and FMS, build FMS, install module files to `deps/include`
and `libFMS.a` to `deps/lib`.
`make clean`
Delete the compiled FMS files in `deps/fms/build` but not the
installed libraries or module files.
`make distclean`
Delete all files produced by the Makefile.
Much of the FMS source configuration has been moved to the `deps`
Makefile. The available hooks and default values are shown below.
```
MKMF_URL ?= https://github.com/NOAA-GFDL/mkmf.git
MKMF_COMMIT ?= master
FMS_URL ?= https://github.com/NOAA-GFDL/FMS.git
FMS_COMMIT ?= 2019.01.03
FCFLAGS_FMS ?=
```
The FCFLAGS_FMS hook is provided to override the default autoconf value,
`-g -O2`.
Although FMS provides its own automake build framework, the 2019.01.03
release cannot be used with MOM6 due to missing components in its
libtool configuration (`random_number`). The build time is also
significantly longer due to incorrect dependencies in the automake
configuration.
Most of the issues describe above have either been or will soon be
resolved in newer FMS releases, and we may be able to transition to
the FMS automake in a future release.
----
The `.testing` directory has been reworked to use the autoconf builds of
MOM6 and FMS, but should otherwise work the same as before.
```
cd .testing
make -j
make -j test
```
The changes required to use autoconf have been incorporated into the
`.testing` Makefile.
This can create issues with the management of FMS, which is now
configured inside of `deps/Makefile` rather than in `.testing`. Also, a
rebuild of FMS will require an explicit wipe of FMS in `deps`, which can
be done with the following command.
```
make -C ../deps distclean
```
Platform-specific flags are now managed in the `config.mk` file rather
than in a mkmf template. The following hooks are provided, with default
values shown.
```
FCFLAGS_DEBUG ?= -g -O0
FCFLAGS_REPRO ?= -g -O2
FCFLAGS_INIT ?=
FCFLAGS_COVERAGE ?=
```
The intention is to provide some correspondence to the GFDL DEBUG and
REPRO production builds.
Any FMS build produced by `make` in `.testing` will use the
`FCFLAGS_DEBUG` variable.
Although `FCFLAGS_INIT` is intended for intialization, it acts as more
of a general-purpose flag which is applied to MOM6 but not FMS.
----
Other points of interest
- This build system only uses autoconf. It does not use automake or libtools.
- autoconf will determine any necessary flags required for building
MOM6, but does not attempt to use optional flags for debugging or
performance.
Flags required for testing or production builds must still track or
otherwise manage their own compiler flags (FCFLAGS, etc).
- The MOM6 `./configure` script requires a FMS library and module files as
part of its build validation. This is why we must pre-build FMS
before calling `./configure`.
- FCFLAGS defaults to `-g -O2`. Any explicit setting of FCFLAGS
will remove and replace these flags. Other flags, such as
`-fdefault-real-8` will be appended as needed and do not need to be
managed.
- Support M4 macros have been tested on GCC, Intel, PGI, and Cray
compilers. The macros can be extended to other compilers and older
versions of these compilers if necessary.
----
Known issues
- The macro used for the MPI launcher (AX_MPI) can potentially locate a
MPIFC (e.g. mpif90) which does not match FC. For example, FC will
tend to default to GFortran, but mpif90 may use Intel Fortran.
While FC is quickly replaced with MPIFC, there are some initial tests
which may fail if FCFLAGS was defined for the non-GFortran compiler.
This can be resolved by explicitly setting both FC and FCFLAGS for the
same compiler.
- Since we use git for both development and distribution, we may want to
pre-build the configure script and support files, eliminating the
`autoreconf` step.
|
I think there are two issues here, first with coverage (probably missing from LDFLAGS) and the other with the target build unable to find the local FMS library. I will try to sort these out in the next commit. |
Minor fixes which include the FCFLAGS coverage flag into LDFLAGS for gcov builds, as well as properly moving the target -L flag out of FCFLAGS and into LDFLAGS.
Codecov Report
@@ Coverage Diff @@
## dev/gfdl #1197 +/- ##
============================================
- Coverage 46.08% 46.07% -0.02%
============================================
Files 214 224 +10
Lines 69399 70583 +1184
============================================
+ Hits 31984 32518 +534
- Misses 37415 38065 +650
Continue to review full report at Codecov.
|
Several build environment variables were redefined globally to be used across all jobs, rather than repeating over every job. The timer output was also redefined to be single line, rather than four, to reduce logging output.
|
This is using the usual gnu environment on gaea login node. |
|
I saw this a few times, it appears to be a Lustre issue. I believe it's hanging because it cannot create the test file. |
Because autoconf can cause fear and anger in some users, the configuration files have now been delegated to a subdirectory, ac, which can be invoked from an arbitrary directory. This required some unconventional constructs in the file, but they have luckily been relegated to a few introductory statements, and the bulk of the code is unchanged. The only pervasive change is the explicit references to the ac directory, particularly ac/deps. .testing also had to be updated to accommodate the autoconf changes.
Modified FMS to build libFMS.a in its build directory, rather than to just target the eventual destination of it (../../lib/libFMS.a). This is because other builds (particularly .testing) may prefer a different destination.
.testing no longer relies on the top-level ac/deps to build and hold its FMS repository. It now checks out its own source and builds its own FMS library exclusively for testing. Also fixed a few dependency bugs in the FMS makefile (and probably in .testing as well). Finally, the m4 macros for FMS were copied into deps, rather than sharing with the top-level m4 macros, allowing it to exist more independently. (I will prune the FMS-specific macros from ac/m4 in a future commit.)
|
The behavior has been modified based on feedback from @adcroft. Autoconf configuration has now been moved into the To create the We may also want to pre-commit the output files ( The To build MOM6: where For a more straightforward build: should also work. MOM6 While |
The AX_FC_CRAY_POINTER macro was heavily updated to better use the intrinsic Autoconf and M4 macros, as well as to introduce both pass/fail macros and an additional PGI test (which doesn't seem needed but *shrug*). Additional processing is no longer needed when invoking this macro. It now automatically applies the Cray pointer flags to FCFLAGS if invoked, and it now automatically aborts of such macros are not supported, although both of these operations can be overridden if necessary. Several FMS macros unused by MOM6 were also removed from the MOM6 m4 macro folder.
…into autoconf_draft
Resolved some bad string parsing issues of the Travis environment variables. Thanks to Inspector Adcroft for discovering this error. Further cleanup of the Cray pointer test macro, should now be very close to conformant Autoconf M4 format.
…into autoconf_draft
|
This is passing now on Travis, but some debug/repro differences are occurring on Gaea which need further investigation. |
This patch adds additional support for building FMS in deps on macOS machines, specifically related to affinity. Much of this can be phased out when we upgrade our target FMS from 2019.01.03 to a newer version. Additional dependency errors in .testing/Makefile have also been fixed related to building of the virtual Python environment.
|
Recent changes include some improved support for macOS, as well as some bugfixes in the Makefile rule dependencies. Thanks very much to @raphaeldussin for his feedback. I think this is close enough to be operational, assuming we are happy with how to use it. But it still needs documentation. |
adcroft
approved these changes
Sep 16, 2020
autoconf now defaults to using symmetric grids, rather than asymmetric grids. The DEBUG/REPRO build comparison is now disabled on default, since many platforms do not produce equivalent results. If this situation improves, then it can be re-enabled.
|
This is ready except for documentation. |
Added several documentation READMEs to using the autoconf build. Also added some changes to the Makefile template so that `make ac-clean` wiped out the autoconf output (configure, aclocal.m4, autom4te.cache).
ac/README.md
Outdated
| ## Coupled builds | ||
|
|
||
| The Autoconf build is currently only capable of building ocean-only | ||
| executables, and cannot yet be build as part of a coupled more, nor as a |
Pointed out by @raphaeldussin
Typo fix
This was referenced Sep 18, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch is a first draft of an autoconf-based build for MOM6.
This is a hybrid solution which relies on mkmf and list_paths to
automatically generate the model dependencies, but uses autoconf to
determine the necessary compiler flags for building the model.
Recommended instructions for testing the build system, as well as
instructions for new users, are shown below.
As with standard autoconf builds, compilers and flags can be configured
with prepended arguments, e.g.
Introduction of autoconf configuration should not interfere with any
existing mkmf-based build procedures.
A more detailed discussion is provided below.
At minimum, only the following instructions would be required:
but this requires that both mkmf and FMS be accessible in standard
searchable directories.
A more realistic MOM6-only build would be as shown below
where
path/to/xxxpoints to the location of the pre-installed content.To alleviate this issue, a Makefile in the
depsdirectory has beenprovided, which checks out copies of mkmf and FMS and places them in the
depsdirectory. If the MOM6./configurescript is unable to findmkmf or FMS, then it will automatically continue to search inside of the
depsdirectory.The
depsdirectory provides templates for an autoconf build of FMSresembling our MOM6 build.
The Makefile provides the following rules:
makeormake all:Fetch mkmf and FMS, build FMS, install module files to
deps/includeand
libFMS.atodeps/lib.make cleanDelete the compiled FMS files in
deps/fms/buildbut not theinstalled libraries or module files.
make distcleanDelete all files produced by the Makefile.
Much of the FMS source configuration has been moved to the
depsMakefile. The available hooks and default values are shown below.
The FCFLAGS_FMS hook is provided to override the default autoconf value,
-g -O2.Although FMS provides its own automake build framework, the 2019.01.03
release cannot be used with MOM6 due to missing components in its
libtool configuration (
random_number). The build time is alsosignificantly longer due to incorrect dependencies in the automake
configuration.
Most of the issues describe above have either been or will soon be
resolved in newer FMS releases, and we may be able to transition to
the FMS automake in a future release.
The .testing directory has been reworked to use the autoconf builds of
MOM6 and FMS, but should otherwise work the same as before.
The changes required to use autoconf have been incorporated into the
.testingMakefile.This can create issues with the management of FMS, which is now
configured inside of
deps/Makefilerather than in.testing. Also, arebuild of FMS will require an explicit wipe of FMS in
deps, which canbe done with the following command.
Platform-specific flags are now managed in the
config.mkfile ratherthan in a mkmf template. The following hooks are provided, with default
values shown.
The intention is to provide some correspondence to the GFDL DEBUG and
REPRO production builds.
Any FMS build produced by
makein.testingwill use theFCFLAGS_DEBUGvariable.Although
FCFLAGS_INITis intended for intialization, it acts as moreof a general-purpose flag which is applied to MOM6 but not FMS.
Other points of interest
This build system only uses autoconf. It does not use automake or libtools.
autoconf will determine any necessary flags required for building
MOM6, but does not attempt to use optional flags for debugging or
performance.
Flags required for testing or production builds must still track or
otherwise manage their own compiler flags (FCFLAGS, etc).
The MOM6
./configurescript requires a FMS library and module files aspart of its build validation. This is why we must pre-build FMS
before calling
./configure.FCFLAGS defaults to
-g -O2. Any explicit setting of FCFLAGSwill remove and replace these flags. Other flags, such as
-fdefault-real-8will be appended as needed and do not need to bemanaged.
Support M4 macros have been tested on GCC, Intel, PGI, and Cray
compilers. The macros can be extended to other compilers and older
versions of these compilers if necessary.
Known issues
The macro used for the MPI launcher (AX_MPI) can potentially locate a
MPIFC (e.g. mpif90) which does not match FC. For example, FC will
tend to default to GFortran, but mpif90 may use Intel Fortran.
While FC is quickly replaced with MPIFC, there are some initial tests
which may fail if FCFLAGS was defined for the non-GFortran compiler.
This can be resolved by explicitly setting both FC and FCFLAGS for the
same compiler.
Since we use git for both development and distribution, we may want to
pre-build the configure script and support files, eliminating the
autoreconfstep.