Closed edhartnett closed 5 years ago
We do have interest in a system like that. We have looked at internally the GNU autotools, cmake and SCONS, and a few others. In fact, the branch user/sdu/cmake is an attempt at using cmake --- the use of a deprecated cmake option in this version is what has kept it from making its way into master.
Since we have little experience with any of these systems standard build systems internally at GFDL and we have the mkmf
system, none of these standard systems have gained adoption out of fear of the scripts getting out-of-date when they are not updated with code changes. All of the developers at GFDL simply rely on mkmf
.
We welcome any pull requests that adopt any of these systems, but it may be left to the community as a whole to keep them up-to-date.
I am working with NOAA GSD on the FV3GFS model, which uses your software.
Since there is not a proper build system for your software, the FV3GFS has to include your code as a subdirectory, in order to get it compiling. This may be contrasted with the use of, for example, netCDF, which is installed independently and is used by many packages, none of which have to include the source code.
While using your non-standard mkmf solution may work well internally, it causes extra work for other scientists using your software, and will not work within part of a larger FV3GFS build system.
For these reasons I urge you to expand your area of concern - it is not just your team who has to build this software, there are now many teams using it. With this larger use, comes larger responsibility.
If I were to create a standard build system for your package, is there someone there who can work with me to help get it working? I need someone who is familiar with how the build works to answer questions.
Although this involves some one-time effort, the reward will be a more flexible, robust, and standard build system, with much greater portability. It will be possible for your users to make use of your software without having to go to extra lengths to get it to build.
And this would allow the FV3GFS system to have a proper build system, enabling much greater usefulness and portability.
@edhartnett the FMS build system is unconventional, but you still end up with largely the same final result, which is a library (lib_fms.a
) and a folder of *.mod
module files, which would need to be in an accessible directory (say /usr/include
) when building your model. One could still compile and distribute these files independently of the model, much like netCDF or any other library dependency, and switching to autotools would not change that.
I'd also be interested in helping to set up a more conventional build tools, but I think it's worth pointing out that AFAIK one does not need to rebuild FMS to use and distribute it, just like netCDF or MPI. Or, if one does, then it's not necessarily anything to do with the build system.
Another point here is that autotools (i.e. configure
etc) alone is not very Fortran-aware and that capturing dependencies into the Makefile (especially around module files) are very difficult to accomplish, and mkmf
is very good at parsing the Fortran source and building a useful Makefile.
Nearly every mature Fortran project that I have seen has some sort of mkmf
, although CMake is a also very good at capturing these dependencies.
I'd also mention that we have at least two people here in our Australian circle who have set up CMake builds of FMS, so it's certainly doable.
(I'll add that it's not my preference, as I'm not much of a fan of CMake. I'd prefer an autoconf script that calls mkmf
or a modern equivalent, but I'm also happy to go with the crowd...)
@marshallward thanks for taking the time to answer my questions and engage on this issue! ;-)
I am the author and a current maintainer of netcdf's build system, including netcdf-fortran. (And I also maintain several other fortran/C library build systems.)
Yes, fortran is quirky, but autotools can handle it just fine. netcdf-fortran builds everywhere, and deals with fortran module issues. It installs fortran based libraries (F77 and F90), using standard 2003 method to communicate with netcdf-c library.
Cmake has it's charms and I also maintain some cmake build systems for C/Fortran libraries. But cmake does not work in this case because I am trying to get a whole FV3GFS build working, and for that I need all the components to play nice with autotools.
I agree that one should not have to rebuild FMS from source to distribute it! But that is the current situation with FV3GFS.
I suspect that the reason the source code for FMS is copied into the FV3GFS build is that it does not have a standard build system. Otherwise they would have it installed as a library. Instead they copy your code from git into a subdirectory, and essentially re-implement the build system in their own build scripts.
So they have a copy of your source code everywhere, and when the FV3GFS gets built, it builds your code too. I would prefer to offer them a proper package that can be installed, and then perhaps we can take the FMS source code out of everyone's build. But even if not, having your package support an autotools build would allow my overall autotools build to work. (Because they nest well.)
If I develop an autotools build for FMS, will you be open to merging it to master?
Can you help by answering my build questions for a week or two?
This would benefit NOAA programmers and sysadmins that have to work with FV3GFS. I am happy to coordinate with the cmake build as well. It's easy to keep both working. There is both a cmake and an autotools build for netCDF, for example, as well as other libraries I work on.
You may even find that it has many benefits over your current system, even setting aside the needs of external users.
I should first say that I am just an FMS user like yourself, so I don't really have any say in how it ought to be done :). But I'm happy to help if I can.
Also I want to apologise for my characterisation of autotools. While I have used autoconf a fair bit, I have not really used automake, which is presumably what netCDF and netcdf-fortran
use, and if it has the capacity to set up Fortran dependences in the Makefile, then I'd definitely be interested to see how it works and pursue that option.
Having said all that, it has always been my experience that FMS can be built and imported independently from the model - exclusively MOM in my case - given that we link to the standalone library and include the *.mod
path.
So I'm surprised to hear that there are problems doing this. But there must be more to it than how I've described it. I'd personally be very interested to learn more here, and happy to help however I can.
Is there anyone from the FMS team reading this? ;-)
As mentioned earlier, we are interested in some of the build systems. I have successfully (with some modification of the code) used the GNU autotools to build the FMS library. It was not adopted in GFDL for the reason specified earlier. And unfortunately, I am unable (currently) to find the directory where I did that work. @edhartnett if you are willing to do the work, I will help as much as possible and answer any questions you may have. Once it is done, and a pull requested created, we will happily merge it into the master branch.
OK, let me take a look and see what I can do. If you find your previous attempt, tell me the branch.
Well my first question is: are there any instructions for the current build system? How do you currently build this code? Thanks!
There is some information on how to build full models, but the process is usually captured in a compile script. I’ll do my best to describe the current build process here. We use two tools: list_paths
and mkmf
. Both of these are included in the NOAA-GFDL/mkmf repository. list_paths
is essentially a wrapper to the Linux find
command to search for all the Fortran and C source code (including headers) files in a given list of directories. The output of list_paths
is an ASCII file with a list (including relative paths) of the source files that have unique names independent of the file’s path. For example, if a directory has the following files with the same name, but in different paths foo/bar/file1
and another/dir/file1
, list_paths
will only return the path to whichever occurs first (after a sort
) and completely ignore the other. The list_path
output file is passed to the mkmf
(Make Makefile) utility. mkmf
uses relatively simple parsing of the source code files to generate a Makefile with the correct file dependencies. mkmf
ignores the Fortran modules, and only deals with the object file. The following steps will allow you to build the FMS
library.
Clone NOAA-GFDL/mkmf, and add to the bin
directory to PATH
.
Clone NOAA-GFDL/FMS. This cloned location will be called <FMS>
in later steps.
In the build directory, run list_paths <FMS>
. This will create a path_names
file.
In the build directory, run: mkmf -c “<CPP_macros>” -I<IncludeDir> -t <make_template> -p libFMS.a path_names
, where <CPP_macros>
are the -D
and -U
to use, -I<includeDir>
are for additional include directories (e.g. netcdf, mpi, etc), use is similar to how -I
is used in the compilers, <make_template>
is for a make template file, samples are in the NOAA-GFDL/mkmf repository.
At this point you will have a Makefile
that can be use to build the FMS library.
OK, thanks, I have tried that and run into some troubles.
I built the makefiles like this:
export PATH=/usr/local/netcdf-c-4.6.2_mpich-3.2/bin/:/home/ed/Downloads/mkmf-19.2.0/bin/:$PATH
export PATH=/usr/local/netcdf-c-4.6.2_mpich-3.2/bin/:/home/ed/Downloads/mkmf-19.2.0/bin/:$PATH
mkmf -c '-DNDEBUG' -I /usr/local/netcdf-c-4.6.2/include -t /home/ed/Downloads/mkmf-19.2.0/templates/linux-gnu.mk -p libFMS.a path_names
This created the makefiles but when I run make I get these errors:
Package mpich2-c was not found in the pkg-config search path.
Perhaps you should add the directory containing `mpich2-c.pc'
to the PKG_CONFIG_PATH environment variable
No package 'mpich2-c' found
Package mpich2-c was not found in the pkg-config search path.
Perhaps you should add the directory containing `mpich2-c.pc'
to the PKG_CONFIG_PATH environment variable
No package 'mpich2-c' found
Package mpich2-f90 was not found in the pkg-config search path.
Perhaps you should add the directory containing `mpich2-f90.pc'
to the PKG_CONFIG_PATH environment variable
No package 'mpich2-f90' found
gfortran -DNDEBUG -fcray-pointer -fdefault-double-8 -fdefault-real-8 -Waliasing -ffree-line-length-none -fno-range-check -I/usr/local/netcdf-c-4.6.2_mpich-3.2/include -O3 -c -I./include -I./mpp/include ./mpp/mpp.F90
gfortran -DNDEBUG -fcray-pointer -fdefault-double-8 -fdefault-real-8 -Waliasing -ffree-line-length-none -fno-range-check -I/usr/local/netcdf-c-4.6.2_mpich-3.2/include -O3 -c -I./include ./drifters/drifters_io.F90
gfortran -DNDEBUG -fcray-pointer -fdefault-double-8 -fdefault-real-8 -Waliasing -ffree-line-length-none -fno-range-check -I/usr/local/netcdf-c-4.6.2_mpich-3.2/include -O3 -c -I./include ./drifters/drifters_input.F90
gcc -DNDEBUG -D__IFC -I/usr/local/netcdf-c-4.6.2_mpich-3.2/include -O2 -c -I./mosaic -I/usr/local/netcdf-c-4.6.2/include ./mosaic/read_mosaic.c
./include/fms_platform.h:114:0:
#define QUAD_KIND DOUBLE_KIND
Warning: "QUAD_KIND" redefined
./include/fms_platform.h:39:0:
#define QUAD_KIND 16
note: this is the location of the previous definition
./mpp/include/mpp_comm_nocomm.inc:1076:0:
#define MPP_TYPE_ integer(INT_KIND)
Warning: "MPP_TYPE_" redefined
./mpp/include/mpp_comm_nocomm.inc:1064:0:
#define MPP_TYPE_ real(DOUBLE_KIND)
note: this is the location of the previous definition
./mpp/include/mpp_comm_nocomm.inc:1077:0:
#define MPI_TYPE_ MPI_INTEGER4
Warning: "MPI_TYPE_" redefined
./mpp/include/mpp_comm_nocomm.inc:1066:0:
#define MPI_TYPE_ MPI_REAL8
note: this is the location of the previous definition
./mpp/include/mpp_comm_nocomm.inc:1080:0:
#define MPP_TYPE_CREATE_ mpp_type_create_int8
Warning: "MPP_TYPE_CREATE_" redefined
./mpp/include/mpp_comm_nocomm.inc:1075:0:
#define MPP_TYPE_CREATE_ mpp_type_create_int4
note: this is the location of the previous definition
./mpp/include/mpp_comm_nocomm.inc:1081:0:
#define MPP_TYPE_ integer(LONG_KIND)
Warning: "MPP_TYPE_" redefined
./mpp/include/mpp_comm_nocomm.inc:1076:0:
#define MPP_TYPE_ integer(INT_KIND)
note: this is the location of the previous definition
./mpp/include/mpp_comm_nocomm.inc:1082:0:
#define MPI_TYPE_ MPI_INTEGER8
Warning: "MPI_TYPE_" redefined
./mpp/include/mpp_comm_nocomm.inc:1077:0:
#define MPI_TYPE_ MPI_INTEGER4
note: this is the location of the previous definition
./mpp/include/mpp_comm_nocomm.inc:1085:0:
#define MPP_TYPE_CREATE_ mpp_type_create_real4
Warning: "MPP_TYPE_CREATE_" redefined
./mpp/include/mpp_comm_nocomm.inc:1080:0:
#define MPP_TYPE_CREATE_ mpp_type_create_int8
note: this is the location of the previous definition
./mpp/include/mpp_comm_nocomm.inc:1086:0:
#define MPP_TYPE_ real(FLOAT_KIND)
Warning: "MPP_TYPE_" redefined
./mpp/include/mpp_comm_nocomm.inc:1081:0:
#define MPP_TYPE_ integer(LONG_KIND)
note: this is the location of the previous definition
./mpp/include/mpp_comm_nocomm.inc:1087:0:
#define MPI_TYPE_ MPI_REAL4
Warning: "MPI_TYPE_" redefined
./mpp/include/mpp_comm_nocomm.inc:1082:0:
#define MPI_TYPE_ MPI_INTEGER8
note: this is the location of the previous definition
./mpp/include/mpp_comm_nocomm.inc:1090:0:
#define MPP_TYPE_CREATE_ mpp_type_create_real8
Warning: "MPP_TYPE_CREATE_" redefined
./mpp/include/mpp_comm_nocomm.inc:1085:0:
#define MPP_TYPE_CREATE_ mpp_type_create_real4
note: this is the location of the previous definition
./mpp/include/mpp_comm_nocomm.inc:1091:0:
#define MPP_TYPE_ real(DOUBLE_KIND)
Warning: "MPP_TYPE_" redefined
./mpp/include/mpp_comm_nocomm.inc:1086:0:
#define MPP_TYPE_ real(FLOAT_KIND)
note: this is the location of the previous definition
./mpp/include/mpp_comm_nocomm.inc:1092:0:
#define MPI_TYPE_ MPI_REAL8
Warning: "MPI_TYPE_" redefined
./mpp/include/mpp_comm_nocomm.inc:1087:0:
#define MPI_TYPE_ MPI_REAL4
note: this is the location of the previous definition
./mpp/include/mpp_comm_nocomm.inc:1095:0:
#define MPP_TYPE_CREATE_ mpp_type_create_logical4
Warning: "MPP_TYPE_CREATE_" redefined
./mpp/include/mpp_comm_nocomm.inc:1090:0:
#define MPP_TYPE_CREATE_ mpp_type_create_real8
note: this is the location of the previous definition
./mpp/include/mpp_comm_nocomm.inc:1096:0:
#define MPP_TYPE_ logical(INT_KIND)
Warning: "MPP_TYPE_" redefined
./mpp/include/mpp_comm_nocomm.inc:1091:0:
#define MPP_TYPE_ real(DOUBLE_KIND)
note: this is the location of the previous definition
./mpp/include/mpp_comm_nocomm.inc:1097:0:
#define MPI_TYPE_ MPI_INTEGER4
Warning: "MPI_TYPE_" redefined
./mpp/include/mpp_comm_nocomm.inc:1092:0:
#define MPI_TYPE_ MPI_REAL8
note: this is the location of the previous definition
./mpp/include/mpp_comm_nocomm.inc:1100:0:
#define MPP_TYPE_CREATE_ mpp_type_create_logical8
Warning: "MPP_TYPE_CREATE_" redefined
./mpp/include/mpp_comm_nocomm.inc:1095:0:
#define MPP_TYPE_CREATE_ mpp_type_create_logical4
note: this is the location of the previous definition
./mpp/include/mpp_comm_nocomm.inc:1101:0:
#define MPP_TYPE_ logical(LONG_KIND)
Warning: "MPP_TYPE_" redefined
./mpp/include/mpp_comm_nocomm.inc:1096:0:
#define MPP_TYPE_ logical(INT_KIND)
note: this is the location of the previous definition
./mpp/include/mpp_comm_nocomm.inc:1102:0:
#define MPI_TYPE_ MPI_INTEGER8
Warning: "MPI_TYPE_" redefined
./mpp/include/mpp_comm_nocomm.inc:1097:0:
#define MPI_TYPE_ MPI_INTEGER4
note: this is the location of the previous definition
./drifters/drifters_io.F90:58: Error: Can't open included file 'netcdf.inc'
./include/fms_platform.h:114:0:
#define QUAD_KIND DOUBLE_KIND
Warning: "QUAD_KIND" redefined
./include/fms_platform.h:39:0:
#define QUAD_KIND 16
note: this is the location of the previous definition
Makefile:65: recipe for target 'drifters_io.o' failed
make: *** [drifters_io.o] Error 1
make: *** Waiting for unfinished jobs....
./drifters/drifters_input.F90:66: Error: Can't open included file 'netcdf.inc'
Makefile:63: recipe for target 'drifters_input.o' failed
make: *** [drifters_input.o] Error 1
./mosaic/read_mosaic.c: In function ‘handle_netcdf_error’:
./mosaic/read_mosaic.c:38:43: warning: implicit declaration of function ‘nc_strerror’; did you mean ‘strerror’? [-Wimplicit-function-declaration]
sprintf( errmsg, "%s: %s", msg, (char *)nc_strerror(status) );
^~~~~~~~~~~
strerror
./mosaic/read_mosaic.c:38:35: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
sprintf( errmsg, "%s: %s", msg, (char *)nc_strerror(status) );
^
./mosaic/read_mosaic.c: In function ‘get_var_data’:
./mosaic/read_mosaic.c:232:3: error: unknown type name ‘nc_type’
nc_type vartype;
^~~~~~~
./mosaic/read_mosaic.c: In function ‘get_var_data_region’:
./mosaic/read_mosaic.c:292:3: error: unknown type name ‘nc_type’
nc_type vartype;
^~~~~~~
Makefile:151: recipe for target 'read_mosaic.o' failed
make: *** [read_mosaic.o] Error 1
./mpp/include/mpp_alltoall_nocomm.h:62:25-25:
subroutine MPP_ALLTOALLW_(sbuf, ssize, sdispl, stype, &
1
Error: Procedure ‘mpp_alltoallw_’ at (1) is already defined at (2)
./mpp/include/mpp_alltoall_nocomm.h:62:25-25:
subroutine MPP_ALLTOALLW_(sbuf, ssize, sdispl, stype, &
1
Error: Procedure ‘mpp_alltoallw_’ at (1) is already defined at (2)
./mpp/include/mpp_alltoall_nocomm.h:62:25-25:
subroutine MPP_ALLTOALLW_(sbuf, ssize, sdispl, stype, &
1
Error: Procedure ‘mpp_alltoallw_’ at (1) is already defined at (2)
./mpp/include/mpp_comm_nocomm.inc:1113:42:
call mpp_error(NOTE, 'MPP_TYPE_FREE: ' &
1
Error: Syntax error in argument list at (1)
./mpp/include/mpp_alltoall_nocomm.h:63:30:
rbuf, rsize, rdispl, rtype, pelist)
1
Error: Array ‘rbuf’ at (1) cannot have a deferred shape
./mpp/include/mpp_alltoall_nocomm.h:63:45:
rbuf, rsize, rdispl, rtype, pelist)
1
Error: Array ‘rdispl’ at (1) cannot have a deferred shape
./mpp/include/mpp_alltoall_nocomm.h:63:37:
rbuf, rsize, rdispl, rtype, pelist)
1
Error: Array ‘rsize’ at (1) cannot have a deferred shape
./mpp/include/mpp_alltoall_nocomm.h:63:52:
rbuf, rsize, rdispl, rtype, pelist)
1
Error: Array ‘rtype’ at (1) cannot have a deferred shape
./mpp/include/mpp_alltoall_nocomm.h:62:30:
subroutine MPP_ALLTOALLW_(sbuf, ssize, sdispl, stype, &
1
Error: Array ‘sbuf’ at (1) cannot have a deferred shape
./mpp/include/mpp_alltoall_nocomm.h:62:45:
subroutine MPP_ALLTOALLW_(sbuf, ssize, sdispl, stype, &
1
Error: Array ‘sdispl’ at (1) cannot have a deferred shape
./mpp/include/mpp_alltoall_nocomm.h:62:37:
subroutine MPP_ALLTOALLW_(sbuf, ssize, sdispl, stype, &
1
Error: Array ‘ssize’ at (1) cannot have a deferred shape
./mpp/include/mpp_alltoall_nocomm.h:62:52:
subroutine MPP_ALLTOALLW_(sbuf, ssize, sdispl, stype, &
1
Error: Array ‘stype’ at (1) cannot have a deferred shape
./mpp/include/mpp_alltoall_nocomm.h:63:30:
rbuf, rsize, rdispl, rtype, pelist)
1
Error: Array ‘rbuf’ at (1) cannot have a deferred shape
./mpp/include/mpp_alltoall_nocomm.h:63:45:
rbuf, rsize, rdispl, rtype, pelist)
1
Error: Array ‘rdispl’ at (1) cannot have a deferred shape
./mpp/include/mpp_alltoall_nocomm.h:63:37:
rbuf, rsize, rdispl, rtype, pelist)
1
Error: Array ‘rsize’ at (1) cannot have a deferred shape
./mpp/include/mpp_alltoall_nocomm.h:63:52:
rbuf, rsize, rdispl, rtype, pelist)
1
Error: Array ‘rtype’ at (1) cannot have a deferred shape
./mpp/include/mpp_alltoall_nocomm.h:62:30:
subroutine MPP_ALLTOALLW_(sbuf, ssize, sdispl, stype, &
1
Error: Array ‘sbuf’ at (1) cannot have a deferred shape
./mpp/include/mpp_alltoall_nocomm.h:62:45:
subroutine MPP_ALLTOALLW_(sbuf, ssize, sdispl, stype, &
1
Error: Array ‘sdispl’ at (1) cannot have a deferred shape
./mpp/include/mpp_alltoall_nocomm.h:62:37:
subroutine MPP_ALLTOALLW_(sbuf, ssize, sdispl, stype, &
1
Error: Array ‘ssize’ at (1) cannot have a deferred shape
./mpp/include/mpp_alltoall_nocomm.h:62:52:
subroutine MPP_ALLTOALLW_(sbuf, ssize, sdispl, stype, &
1
Error: Array ‘stype’ at (1) cannot have a deferred shape
./mpp/include/mpp_alltoall_nocomm.h:63:30:
rbuf, rsize, rdispl, rtype, pelist)
1
Error: Array ‘rbuf’ at (1) cannot have a deferred shape
./mpp/include/mpp_alltoall_nocomm.h:63:45:
rbuf, rsize, rdispl, rtype, pelist)
1
Error: Array ‘rdispl’ at (1) cannot have a deferred shape
./mpp/include/mpp_alltoall_nocomm.h:63:37:
rbuf, rsize, rdispl, rtype, pelist)
1
Error: Array ‘rsize’ at (1) cannot have a deferred shape
./mpp/include/mpp_alltoall_nocomm.h:63:52:
rbuf, rsize, rdispl, rtype, pelist)
1
Error: Array ‘rtype’ at (1) cannot have a deferred shape
./mpp/include/mpp_alltoall_nocomm.h:62:30:
subroutine MPP_ALLTOALLW_(sbuf, ssize, sdispl, stype, &
1
Error: Array ‘sbuf’ at (1) cannot have a deferred shape
./mpp/include/mpp_alltoall_nocomm.h:62:45:
subroutine MPP_ALLTOALLW_(sbuf, ssize, sdispl, stype, &
1
Error: Array ‘sdispl’ at (1) cannot have a deferred shape
./mpp/include/mpp_alltoall_nocomm.h:62:37:
subroutine MPP_ALLTOALLW_(sbuf, ssize, sdispl, stype, &
1
Error: Array ‘ssize’ at (1) cannot have a deferred shape
./mpp/include/mpp_alltoall_nocomm.h:62:52:
subroutine MPP_ALLTOALLW_(sbuf, ssize, sdispl, stype, &
1
Error: Array ‘stype’ at (1) cannot have a deferred shape
./mpp/mpp.F90:839:22:
module procedure mpp_alltoall_logical8_w
1
Error: Procedure ‘mpp_alltoall_logical8_w’ in generic interface 'mpp_alltoall' at (1) is neither function nor subroutine
./mpp/mpp.F90:755:22:
module procedure mpp_sum_int4_5d_ad
1
Error: Procedure ‘mpp_sum_int4_5d_ad’ in generic interface 'mpp_sum_ad' at (1) is neither function nor subroutine
Makefile:119: recipe for target 'mpp.o' failed
make: *** [mpp.o] Error 1
OK, so first question: do I modify the Makefile to use mpifort instead of gfortran? Or is there some other way to do that?
I'm out of the office today, so I'll do my best to reply using my phone. The templates available in the NOAA-GFDL/mkmf are a best efforts samples. Settings in the template will need to be modified for your particular system. A good location for instructions to build FMS on general Linux systems can be found in the NOAA-GFDL/MOM6-examples wiki pages, in particular the getting started guide. You can also look at the script used to build FMS on a traivis-ci system.
Sent with GitHawk
Awesome, thanks I will take a look!
OK I have made some modifications to my template file to try and get it to work.
Currently I am seeing the following when I do make. Are these warnings expected or am I doing something wrong?
mpifort -DNDEBUG -fcray-pointer -fdefault-double-8 -fdefault-real-8 -Waliasing -ffree-line-length-none -fno-range-check -I/usr/local/netcdf-c-4.6.2_mpich-3.2/include -I/usr/local/netcdf-fortran-4.4.5_c_4.6.2_mpich-3.2/include -O3 -c -I./include -I./mpp/include ./mpp/mpp.F90
mpicc -DNDEBUG -D__IFC -I/usr/local/netcdf-c-4.6.2_mpich-3.2/include -O2 -c -I./mosaic -I/usr/local/netcdf-c-4.6.2/include ./mosaic/read_mosaic.c
./include/fms_platform.h:114:0:
#define QUAD_KIND DOUBLE_KIND
Warning: "QUAD_KIND" redefined
./include/fms_platform.h:39:0:
#define QUAD_KIND 16
note: this is the location of the previous definition
./mpp/include/mpp_comm_nocomm.inc:1076:0:
#define MPP_TYPE_ integer(INT_KIND)
Warning: "MPP_TYPE_" redefined
./mpp/include/mpp_comm_nocomm.inc:1064:0:
#define MPP_TYPE_ real(DOUBLE_KIND)
note: this is the location of the previous definition
./mpp/include/mpp_comm_nocomm.inc:1077:0:
#define MPI_TYPE_ MPI_INTEGER4
Warning: "MPI_TYPE_" redefined
./mpp/include/mpp_comm_nocomm.inc:1066:0:
#define MPI_TYPE_ MPI_REAL8
note: this is the location of the previous definition
./mpp/include/mpp_comm_nocomm.inc:1080:0:
I have been trying to use the mkmf build system. And I will continue to hammer away at it to see if I can get a working build.
It's pretty amazing to me that anyone could think mkmf is a good idea.
You don't try to write your own fortran compiler for the project, similarly you should not attempt to write your own build system tools, and for the exact same reason: you will never equal the capability of the standard software that has been around for decades. What you end up with is just an expensive, very inferior replacement for something that was already freely available to you at no charge.
Tools already exist for this, and you should use them.
mkmf
began life around March 1999. I'm not sure what Fortran support was available in other build systems at that time, but as there aren't may now, my guess is there were even fewer then. I don't know when autoconf first had support for Fortran.
Since mkmf
is what GFDL had from 1999, it has continued as it is what the GFDL developers know and it is what the GFDL workflow software uses. mkmf
also works for the NOAA-GFDL/MOM6 developers, which is done on multiple systems across the world -- I do admit most of them simply copy/paste the commands they use, and some of the templates in NOAA-GFDL/mkmf are there for MOM6.
mkmf
has many shortcomings, and it can be difficult to get a successful build. Most of the difficulties in getting a successful build are deficiencies in the FMS documentation, rather than deficiencies in mkmf
. But for the FMS developers, it is easier to continue to use mkmf
than to learn one of the other build systems.
Adopting one of the standard build systems is ideal, now, as the community base has expanded outside of GFDL, and FMS is used in non-GFDL models. However, it will still take time (and resources) for the internal GFDL community (and the workflow software) to adopt a new build system.
I'm sorry to sound negative.
I have a build system for you now that is pretty complete, I believe, but it is failing just like the mkmf build is. So something about how I am building is not working.
If I could get the mkmf build working one time, I will learn the secret sauce and will encode it into the standard build system.
OK, anyone interested should try out the build system currently up in PR #60 . Comments welcome.
It would be great if there was a standard build system, such that I could do ./configure && make.
Do you guys have any interest in such a system?