Closed nuclearfusionreactor closed 1 year ago
Hmm. Definitely seems to be some issue with CMake "sort of" finding things but not really.
Could you send the cmake command you used to generate the output above? Also did you clone pFUnit with --recursive
? Just want to be sure I know how pFUnit should be finding gFTL. (Unfortunately, different users want different mechanisms for this, so the CMake logic has become complex/fragile.)
My next thought is to ensure that CMake does not try to use anything global by explicitly specifying CMAKE_PREFIX_PATH
and CMAKE_INSTALL_PREFIX
on the command line. If this works then we just need to understand why cmake is doing the other thing with the original command.
The output above was produced with cmake ..
inside of the Build-directory.
pFUnit was not cloned with --recursive
I made a try with
cmake -DCMAKE_PREFIX_PATH=/local/path/Programs/pFUnit/ -DCMAKE_INSTALL_PREFIX=/local/path/pFUnit/Build/installed/ ..
but I get still the same error message. (The same if I point CMAKE_PREFIX_PATH
to the Build
subdirectory).
with kind regards nuclearfusionreactor
Can you set the CMAKE_PREFIX_PATH
also to /local/path/pFUnit/Build/installed/
? I want to rule out other things being in the path you specified interfering. (And be sure to wipe out any detritus in the build dir from the first attempt, of course.)
Using cmake -DCMAKE_PREFIX_PATH=/local/path/Programs/pFUnit/Build/installed/ -DCMAKE_INSTALL_PREFIX=/local/path/Programs/pFUnit/Build/installed/ ..
leads to the same error.
with kind regards nuclearfusionreactor
Hmm. My next suggestion is to start from either a full recursive clone from the repo or the full tar file and repeat the previous step. (Note that the default GitHub tar ball does not include submodules, but a script adds a full tar ball in the "Assets" list for each recent release. E.g., the most recent release has pFUnit-v4.4.2.tar
.)
A new clone with --recursive
does lead to the same message.
Using pFUnit-v4.4.2.tar
also leads to the same message, as does pFUnit-v4.2.7.tar
. pFUnit-v4.1.14.tar
on the other hand works with cmake ..
and then make
. I have not yet tried to use this version with configuring/compiling a project.
Edit: Version pFUnit-v4.2.0.tar
also fails. v4.1.15
does not have a .tar
file.
Edit2: 4.1.4
finds gftl in /usr/share/cmake/gftl_shared/
, 4.2.0
finds fargparse in /usr/share/cmake/fargparse/
but neither /usr/share/cmake/gftl_shared/GFTL_SHAREDConfig.cmake
nor /usr/share/cmake/gftl/GFTLConfig.cmake
.
Hmm. These latest facts at least provide some sort of clue as to what is causing a problem. I can at least take a look at the changes in the subsequent versions to see what might be causing issues for cmake.
But since 4.2.7 is building and installing on several systems on my end, there would still seem to be some system dependency that is playing a role. Clearly it is not the compiler, and GFortran 11.2 is fine in any event. The CMake you are using is a bit older than what I have on my system, but we've not really been pushing the envelope on CMake issues. I'm going to check with a colleague that's a bit more experienced with CMake to see if they have any theories here.
@nuclearfusionreactor We have a thought. My current guess is the gftl, gftl_shared, and fargparse in your /usr/share
might be too old for current pFUnit and maybe that is causing the issue. (We often fix bugs to GFE libraries which means they need to all be "of the right vintage").
One course is to update all the other GFE libraries on your system to the latest version, but we have a test you could do before that. So, could you clone pFUnit 4.4.2 again and then do:
cmake .. -DCMAKE_SYSTEM_IGNORE_PREFIX_PATH='/usr/share/cmake'
Our thought is CMake is really good at finding things on a system and maybe it's finding the old libraries and GFE isn't testing to make sure they are a new enough version. But if you tell CMake to ignore that path, it might then try using the internal versions from pFUnit.
Note, you might need to try:
-DCMAKE_SYSTEM_IGNORE_PREFIX_PATH='/usr/share'
instead or as well. Not sure exactly what's right, but I figure try the longest path first then slowly remove.
I made a clone with --recursive of the repository and tried it with
cmake .. -DCMAKE_SYSTEM_IGNORE_PREFIX_PATH='/usr/share/cmake'
Also with '/usr/share/', and with different order of ..
and -D
. I also tried to explicitly remove the gftl folders, but neither did work.
However I think this is because the -DCMAKE_SYSTEM_IGNORE_PREFIX_PATH
did not do what was expected. I think so because output of cmake with --debug-find
says that fargparse
is still found in /usr/share/cmake/fargparse/FARGPARSEConfig.cmake
, which should not be the case.
with kind regards nuclearfusionreactor
Ah. Looking at its help page it was introduced in CMake 3.23 and you are older than that. It worked for me because we have that version.
Well, if it's easy for you, you can try updating CMake. Otherwise, I'll look around to see if there is an older way of doing what that setting does.
Also, if you have a chance, can you go to /usr/share/cmake
and see if you can determine what versions of GFE libraries you have? Should be visible in the Config-version.cmake
files.
There is no GFE library in that folder. If you meant GFTL then it is 1.2.7, for GFTL_SHARED it is 1.0.7
There is no GFE library in that folder. If you meant GFTL then it is 1.2.7, for GFTL_SHARED it is 1.0.7
Ah. Sorry. GFE is the "Goddard Fortran Ecosystem" which gFTL, gFTL-shared, fArgParse, etc. are part of. I just think of it in those terms. It's also an "omnibus" repo that @tclune maintains here: https://github.com/Goddard-Fortran-Ecosystem/GFE which has consistent versions of all libraries.
And those are quite old. My guess is you probably need to update them. For example in the latest GFE release, we have:
If you can't update CMake to ignore /usr/share/cmake
then your best bet might be to update any GFE libraries you have installed to the latest version, and then pFUnit will probably be happy.
@nuclearfusionreactor Were you ever able to successfully build? Apologies for losing track of this ticket - my hope was the last response from @mathomp4 above would suffice.
Sorry for the late reply, this was a side project and thus not of high priority.
As I did the tests already a while ago I am not sure I can remember all of it correctly.
Bu I hope I remember the most important point correctly:
CMAKE was updated and I think I could get it to ignore /usr/share/cmake
(I can not reproduce this now).
But this did not help, neither for the 'normal' checkout nor for the recursive.
My stand at the moment is, that the problem is due to an issue with the local installation, and thus there is not much that you can do about this.
I thus decided to close this now as done.
With kind regards, nuclearfusionreactor
Hello,
I have some trouble using/configuring pFUnit.
When cloning the repository and trying to configure pFUnit I get an error message that
gFTL
could not be found (git 2.30.2, cmake 3.18.4, i have internet connection). Full error message see below. As far as I understood, submodules should be downloaded during configuration, so as the error messge saysThis should not happen
. Note: there seems to be a global installation ofgFTL
on our system.As it is also cmake related: Our administrator had version 4.1.9 installed (or created a package and then installed). However, when trying to configure a project using this version, cmake gives an error message from
/usr/share/cmake/pfunit/PFUNITConfig.cmake:15
, thatinclude could not find load file: /usr/share/cmake/fargparse/PFUNIT.cmake
(of course there is noPFUNIT.cmake in
fargparsebut there is one in
pfunit`).With kind regards nuclearfusionreactor