-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[cmake] Assume XRootD >= 5.0.0 and migrate to XRootDConfig.cmake
shipped by XRootD
#13752
Conversation
9b6f721
to
ed9ff80
Compare
net/netxng/CMakeLists.txt
Outdated
@@ -21,7 +21,7 @@ ROOT_STANDARD_LIBRARY_PACKAGE(NetxNG | |||
src/TNetXNGSystem.cxx | |||
src/RRawFileNetXNG.cxx | |||
LIBRARIES | |||
Xrootd::Xrootd | |||
${XROOTD_LIBRARIES} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should try to link only against the client libraries. I bet there's a part in the upstream FindXROOTD.cmake
that allows for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there is. I'll try to use it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It works, the PR is updated
Hi! Just as an update on testing this PR: I tried to build ROOT with xrootd with xrootd from this branch here, to see if it gets correctly picked up also with this PR: And it works fine without the |
ed9ff80
to
4cbd582
Compare
|
||
# By the presence of the XrdClient/XrdClientAdmin.hh header, we check if netx can be compiled (XRootD < 5.0.0). | ||
set(CMAKE_REQUIRED_INCLUDES ${XROOTD_INCLUDE_DIRS}) | ||
check_include_file_cxx(XrdClient/XrdClientAdmin.hh _xrd_client_admin_hh) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This just accidentally might find header files in system locations? Can you add a if (xrootd VERSION_LESS 5) around this or something?
cf. #11750 where libraries from different xrootd installations were mixed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, that's a great idea!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, now I remember why I didn't do this obvious thing! It's because XRootD only includes the version info in the latest releases:
xrootd/xrootd#2015
Until then, we either keep a more rigurous version check line in our old FindXROOTD.cmake
, or we use a less verbose hack like this. Considering that XRootD is already at its end of support, I don't think it's worth to spend much time optimizing this. I think in ROOT we are anyway going to remove soon the components that require XRootD 4.
But maybe @amadio has a better idea!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But the problem really is that you might have more than one xrootd in your paths somehow, so you really shouldn't pick up these header files if you already know that you are not compatible.
Something like?
# if we don't have any version information from the XROOTD cmake, let's just try
# to pick up some header files
if(NOT XRootD_VERSION_MAJOR OR XRootD_VERSION_MAJOR VERSION_LESS 5)
#...
endif()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, yes that makes sense. So in that case, you can be sure that at least if you have a new xrootd with version variables (which I presume you do in LCG, right?), then the old headers will not be detected.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we have a fairly recent xrootd (5.6.0)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, and thanks again for your feedback! I think I addressed your issue now, can you check if #11750 is fixed?
Now, if you have xrootd > 5.6.0
installed and you don't use builtin_xrootd
, there should be nothing in the cmake code path besides standard find_package()
and version checks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think for now it might be necessary to keep your own module, but simply require a new version and drop all deprecated code using XRootD 4.x. I will fix XRootDConfig.cmake
to properly export a version in the next feature release, then you will be able to call find_package(XRootD 5.7)
and finally drop FindXROOTD.cmake
from ROOT.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've created a ticket on XRootD for this: xrootd/xrootd#2094
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's great, thank you!
FindXROOTD.cmake
and work around XRootD version checkXRootDConfig.cmake
shipped by XRootD
4db3a22
to
2efa0b5
Compare
Note that XRootD 5.6.3 has been released, and now exports the version via CMake. |
Awesome @amadio! I will take a look |
2efa0b5
to
ec49341
Compare
Starting build on |
XRootDConfig.cmake
shipped by XRootDXRootDConfig.cmake
shipped by XRootD
Hi @amadio, the situation also changed a bit because we deprecated I think we should just assume now that XRootD will be at least version 5, since version 4 is EOL for two years already and we have no non-deprecated featured depending on XRootD 4. @andresailer, would this fix your issues?
@amadio, does that make sense from the XRootD perspective? @Axel-Naumann, what do you think? This does add some extra step when we want to resurrect the XRootD 4 dependent features, but this would not be easy anyway (if they even work with eos 4 also being EOL) |
Yes, XRootD/EOS 4.x are both EOL at the end of this year. All EOS instances will be on EOS 5.x by then. If you can, depend on XRootD from EPEL, as it's well maintained by @ellert. On Debian/Ubuntu, however, due to their restrictions on updating packages to newer versions, you may want to carry the builtin just in case for the older releases. Depending on when you plan to release ROOT 6.30, XRootD 5.6.3 (current release) or 5.7.0 (upcoming feature release early December) should be used for the builtin, to have the fixed CMake module exporting a version. Let me know if you have any other questions. |
ec49341
to
0ed3f8a
Compare
Starting build on |
|
If you mean with XRootD 4 headaches the problems that show up when old XRootD 4 is still installed on the system, then yes (see the issues linked to this PR). We now use the FindXRootD from XRootD, and not our own, which is better in dealing with those cases. Like this one: Edit: ah you were talking about the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, if it works 😉
Xrootd 4 reached end of life in september 2021: https://xrootd.slac.stanford.edu/ Therefore, we can assume now that xrootd will always be at least that version, which greatly simplifies the configuration. The version checks were used in two places: * To check if `xproofd` can be built. But `xproofd` is removed in ROOT 6.32. * To determine whether to build `netx` and/or `netxng`. Now we just biuld `netxng` whenever XRootD is available. `netxng` requires XRootD > 3.3.5, which should be a given at this point. The old `netx` required XRootD < 5.0.0, which is EOL and should not be used anymore.
Migrates finding XRootD to the `XRootDConfig.cmake` from XRootD itself.
0ed3f8a
to
6e7798e
Compare
Starting build on |
Just rebasing on master to see if it actually still works |
This broke the build on all EPEL-based distributions where the headers are in |
Assume that XRootD will always be >= 5.0.0 since version 4 is EOL for two years now and all the ROOT features that need XRootD 4 are deprecated by now.
Migrates finding XRootD to the
XRootDConfig.cmake
from XRootD itself.