Open kurtsansom opened 3 years ago
an example error would be
/build/external/pfunit_src/extern/fArgParse/src/BaseAction.F90:309.6:
n_arguments = this%n_arguments
1
Error: Assignment to an allocatable polymorphic variable at (1) is not yet supported
There is currently a bit of a mess in the Cmake logic across the GFE components in pFUnit. Some contributed code broke some cases that are not covered by the CI. I spent a fair bit of time last weekend trying to unravel the problem, as has the contributor. I'm having a meeting with him tomorrow morning where we hope to work through the issues and get things back to being more stable.
In the mean time I recommend going back to v4.1.14 which should work. (Please scream if not.)
The n_arguments
issue is a separate technical problem. Intel and gfortran need conflicting workarounds for compiler defects. I think that was resolved in 4.1.14 but because of the submodule issue it is possible that something was not correctly updated. As soon as I can get the cmake issue unraveled, I will go through and prepare a table of which compiler versions currently work. I hope that 8.x is still in the list, but I certainly recommend 9 or 10 at this point.
cmake issues aside: I was able to get gcc-7.5 to compile pfunit. all prior compilers failed. 4.9, 5.5, and 6.5 pfunit works with gcc-7.5 with the following flags.
-D CMAKE_BUILD_TYPE=Release \
-D SKIP_ESMF=ON \
-D SKIP_MPI=ON \
-D ENABLE_TESTS=OFF \
Hi all, I'm using gfortran 5.4.0. I can do "cmake .." in versions 4.2.1, 4.1.4 and 3.3.0. But, only version 3.3.0 pass the compiling at "make tests", Other versions generate the error below and others related:
an example error would be
/build/external/pfunit_src/extern/fArgParse/src/BaseAction.F90:309.6: n_arguments = this%n_arguments 1 Error: Assignment to an allocatable polymorphic variable at (1) is not yet supported
Newer versions of pFUnit require more recent versions of gFortran. That particular issue is only the first of many you will encounter when trying to use GFortran 5.x. I recommend using GFortran 9 or 10. You might be able to get away with 8 for some use cases. (Or use the older pfunit ...)
Cheers
Thank you Tom for your prompt reply.
I've used fPUnit version 3 before. There's a lot to upgrade if I upgrade gfortran. :-) Now i'm wondering what are the news in 4.* versions. I'checked the documentation over documentation folder, in github, but there's only a pdf for version 3.
Best, Denis
To a large extent pFUnit 4.0 was just a major cleanup of 3. The new design is more extensible - e.g., pfunit is now just an extra layer/library on top of the serial funit.
I did have some hopes for the utility of the new fHamcrest layer, but in practice it is limited both because of compiler bugs and Fortran's single inheritance.
If 3.x does what you need with the compilers you want to use, you should be fine. Support will be limited though, of course. I should delete the 3.x documentation in the main branch. Unfortunately, I do not have any funding to get equivalent documentation written for 4.x. (If there are specific issues though, I'm happy to update the README file.)
Thanks Tom, I intend to use it more in Numerical Weather Forecast models at CPTEC INPE (Brazil) to do some unit tests, aiming to use it for new developments. I hope to be able to contribute to the development of pFUNit.
Just noting here that GCC-7 compilation started to fail with internal compiler error when compiling fArgParse (which was apparently updated via submodule in this repo 7 days ago).
internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-7/README.Bugs> for instructions.
extern/fArgParse/extern/gFTL-shared/src/v2/CMakeFiles/gftl-shared-v2.dir/build.make:1426: recipe for target 'extern/fArgParse/extern/gFTL-shared/src/v2/CMakeFiles/gftl-shared-v2.dir/ordered_map/Integer32Complex128OrderedMap.F90.o' failed
Hmm. I did not think gcc-7 was working with pfunit even before that change. Any chance you can adapt to a more recent gcc? I can attempt a workaround next week, but ... it's always a bit fun to find workarounds in the older compilers.
In the mean time, you can create your own branch that uses earlier fArgParse. The updates were mostly just to get everything up to the latest gFTL for an indirect purpose.
@tclune no worries and thanks for the reply. GCC-7 works as long as the new fhamcrest functionality is disabled (via cmake config -DSKIP_FHAMCREST=YES
). We're using that version as that is the most recent version on some of our compute clusters (and I am not an admin there so cannot easily update). As a workaround I'm going to pin the pfUnit version to the last working commit.
Here's my build script for pFUnit that I use in Github Actions in case it's of interest.
https://github.com/PHOTOX/ABIN/blob/master/dev_scripts/install_pfunit.sh
It appears that pfunit CI/CD tests with gcc-8 and up, and I am having an issue compiling the submodules with gcc-4.9. but there are also old documents that mention earlier versions
Is there a definite minimum gcc version that pfunit should work with?