Closed osdesy closed 4 years ago
@rete how can we fix this ?
The ILCSoft.cmake script in /afs/desy.de/project/ilcsoft/sw/x86_64_gcc82_centos7/v02-01
sets the CMAKE_PREFIX_PATH to a location where Eigen3 can be found, namely:
`/afs/desy.de/project/ilcsoft/sw/x86_64_gcc82_centos7/eigen/3.3.7/share/eigen3/cmake/`
You don't need to use the GBL FindEigen3.cmake macro for that. Find your GBL package and then the Eigen3 package:
find_package( GBL REQUIRED )
find_package( Eigen3 REQUIRED )
Can you have a try like this please?
Yes, thanks, I will try that. First attempt at least ran through with version 3.3.7 required. However, now I have to figure out how to print that as a message to the cmake output (Version, Path). The previous methods using the script obviously don't work anymore.
Eigen3 with this version uses CMake targets as the user interface. It means you have to do something like:
target_link_libraries( MarlinTPC PUBLIC Eigen3::Eigen )
This sets up include directories, library linking if any (not in this case normally) and definitions such as specific compiler flags, etc... For getting target properties, I let you refer to the CMake documentation. The properties sets by Eigen3 in /afs/desy.de/project/ilcsoft/sw/x86_64_gcc82_centos7/eigen/3.3.7/share/eigen3/cmake/Eigen3Targets.cmake
, in addition to the variables defined in /afs/desy.de/project/ilcsoft/sw/x86_64_gcc82_centos7/eigen/3.3.7/share/eigen3/cmake/Eigen3Config.cmake
.
OK, thanks for the pointer. With your suggestion it works and finds the correct version - at least in ilcsoft v02-01. However, I will for the moment still use the deprecated EIGEN3_VERSION_STRING and similar variables, as Eigen3 doesn't seem to be used as a library in MarlinTPC (in contrast to the other dependencies). Only its include directories are used and I need to find out, whether this is historical legacy by now or has a deeper reason. I remember that we had to make all this extra scripting effort, because the GBL version and maybe Eigen was not found correctly in past releases. I think this can be closed a s solved for now.
Even if Eigen3 has no compiled library, the CMake command:
target_link_libraries( MarlinTPC PUBLIC Eigen3::Eigen )
still applies. This a bit weird construct in this case, but Eigen3::Eigen is an imported target, so this call will just takes care of doing everything you need under the hood, namely setting up include directories for the MarlinTPC target.
Yes, I understand, that also for such template libraries that would be the way to go. However, at the moment specifically only the include files get added and only if GBL is found in the right version. Otherwise the entire thing is left out. All other dependencies are simply added in the way you described, in a loop. Maybe that construct breaks, if simply adding Eigen3 to the list - there must have been a reason to do it in such a complicated way. As I said, some historical research and discussion with users is needed. Don't worry, refactoring CMakeList.txt is definitely on the ToDo-list. In fact a completely modernized version was already written a few years ago, just that iLCSoft didn't use the required CMake version at the time, yet, and now other things have changed, as well.
Hi,
while refactoring MarlinTPC, I discovered several warnings from Eigen3, installed in /usr/include/eigen3, in the compiler output! Setting aside the question, why I get them in compiling MarlinTPC, I checked on the log of my cmake-run, which I put in attachment (cmresmod.txt), and indeed it uses the correct GBL script to find Eigen3, but this then finds the local installation instead of the afs one. This looks similar to the issue with GSL in #83, only that this time all versions seem up-to-date and fitting together:
Some time ago, we implemented a special switch for GBL in MarlinTPC's CMakeLists.txt, because in older versions it didn't use Eigen, but root and the version string was not filled properly. However this seems to work as intended here, as the correct GBL-version is identified. So I guess it is something in GBL's find script for Eigen3:
From what I get from the find script in GBL, it could also be, that the find script just refers to the default version of Eigen3 and that is fulfilled by the local installation, and that is why it doesn't bother to look in afs? As you see, we don't have a requirement on Eigen3 version from MarlinTPC. If I require version 3.3.7 (the one from afs installation), indeed cmake crashes:
It also still reports the policy problem CMP0074 with MarlinUtil. As the MarlinUtil_ROOT variable is set there in its MarlinUtilConfig.cmake, the policy switching to OLD or NEW should be in there, shouldn't it? I'm not sure, if that has anything to do with the Eigen3 problem, though.
Environment: I'm compiling on naf-ilc, so centos7 and using the respective installation in afs at:/afs/desy.de/project/ilcsoft/sw/x86_64_gcc82_centos7/v02-01 There is no cvmfs version, yet, is there?