Open rjdave opened 3 years ago
OK, thanks for finding this.
I thought I was doing a make distcheck in the CI, which should have caught this.
An in source build does (mostly) work for me. I say mostly because test_darray_async_many fails but that might partially be due to the fact that I set CFLAGS, FFLAGS, and FCFLAGS to -O3 since the cmake build passed that test and appears to have been built with "-debug minimal -O0". If I disable that one test 'make check' completes successfully.
That said, I did find another issue with vbuilds. After adding "-I../../src/flib" to CPPFLAGS the build system gets further but fails when looking for tests/general/util/pio_tf_f90gen.pl. Again, this perl script is in the source code but never copied to the build path.
FYI: I happen to be looking at the pio 2.5.4 release tarball yesterday and noticed that it has the compiled .mod files in src/flib again. I DID NOT attempt to do a vbuild to determine if the -I/path/to/src/flib and copying of tests/general/util/pio_tf_f90gen.pl is still necessary.
I will not have time to look at this until the end of the Summer at the earliest. I'm all booked up until then. ;-)
If you want to submit a PR with fixes, that would be most welcome...
OK, this is the CMake build, correct?
You say:
it has the compiled .mod files in src/flib again.
Do you mean we fixed this and then it broke again?
Do you know what the fix for this should be?
No this is not CMake - it's autoconf.
OK, I will check...
This is with autotools. I have only compiled 2.5.3 and 2.5.4 so I don't know if this used to work or not
vpath autotools builds don't work regardless of whether the source code is obtained with a git clone
or release tarball because:
git clone
) or the mod files that are there are built with the wrong compiler (release tarball).In-source autotools builds from a release tarball source code fail because:
However, if make clean
is issued before make
the problem goes away because make clean
removes the compiled .mod files in src/flib.
In-source autotools builds from a git clone
obtained source code do not have an issue since:
The already compiled .mod files problem appears to be confined to the src/flib directory as the release tarball does not contain .mod or .o files in any other directories.
The way I successfully do a vpath build is to run configure with -I../../src/flib
added to CPPFLAGS. Then, after configure completes, I copy tests/general/util/pio_tf_f90gen.pl
from the source code into the same directory in my build tree. Then I run make
, remove "test_darray_async_many" from tests/cunit/run_tests.sh
( #1867), make check
, and make install
.
I am attempting to build PIO 2.5.3 on Linux with the Intel 17 compilers using MVAPICH2-2.2. I cloned the github repository, checked out the 2.5.3 tag, and ran
autoconf -i
. I am attempting a vpath (out of source) build using the configure script. here is a (severely) slimmed down version of the configure command I'm using:../../pio/configure CC=mpicc FC=mpifort --enable-fortran --disable-shared --enable-netcdf-integration
the configure completes so I execute make and it errors here:
The issue is that the compiled pio.mod file is at ../../src/flib (inside the build directory) not ../../../../pio/src/flib (inside the source directory). The compile line should have an include for src/flib in the build directory.
I'm not yet sure if the includes need to be corrected or if an extra include needs to be added. I will let you know if I gather any more details. For now I will try cmake or an in-source build and see if that goes more smoothly.
Interestingly, the 2.5.3 gzipped tarball downloaded from github actually has compiled .mod files in the source code so the error changes to
error #7013: This module file was not generated by any release of this compiler.