Include cmake or pkg-config modules

[bbockelm]

Many other C++ projects actually ship suggested CMake modules for compiling/linking against their projects. It provides a standard technical point-of-reference for using the project's modules.

For example, if I need the boost python module, I simply have to add the following to my CMakeLists.txt:

find_package( Boost REQUIRED COMPONENTS python )

and I can then reference Boost_PYTHON_LIBRARY and BOOST_INCLUDE_DIRS as needed. I'd love to see something similar provided by Xrootd.

I use standard macros for libraries like boost or python, but for Xrootd I find myself copy / pasting from older projects into my newer projects. That means I copy/paste bugs and don't get any improvements from upstream -- for example, I'm certain I'm not handling the library suffix (-4) correctly.

Now, there's a reasonable argument for-and-against the use of CMake specifically (for: it's likely the dominant C++ build system and covers ROOT and EOS; against: don't want to impose upon externals). In that case, the pkg-config is the standard way of doing things -- and hooks into almost every build system out there. It just isn't as expressive or useful for C++ projects.

[xrootd-dev]

+1 for pkg-config. It may not support exotic library placements, yet it does support well normal setups. If one needs more sophistication, he can always use a FindXrootd.cmake macro, probably like the one that more or less everyone uses now. I also agree that such a high quality macro would be a nice addition to the base packages. Cheers Fabrizio

…

On 09/17/2017 11:26 PM, Brian Bockelman wrote: Many other C++ projects actually ship suggested CMake modules for compiling/linking against their projects. It provides a standard technical point-of-reference for using the project's modules. For example, if I need the boost python module, I simply have to add the following to my |CMakeLists.txt|: |find_package( Boost REQUIRED COMPONENTS python ) | and I can then reference |Boost_PYTHON_LIBRARY| and |BOOST_INCLUDE_DIRS| as needed. I'd love to see something similar provided by Xrootd. I use standard macros for libraries like boost or python, but for Xrootd I find myself copy / pasting from older projects into my newer projects. That means I copy/paste bugs and don't get any improvements from upstream -- for example, I'm certain I'm not handling the library suffix (|-4|) correctly. Now, there's a reasonable argument for-and-against the use of CMake specifically (for: it's likely the dominant C++ build system and covers ROOT and EOS; against: don't want to impose upon externals). In that case, the |pkg-config| is the standard way of doing things -- and hooks into almost every build system out there. It just isn't as expressive or useful for C++ projects. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#582>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AD7YjmLY58K3V6JnRqjsgbzL6ofOmBWrks5sjY6XgaJpZM4PaSUK>. -------------------------------------------------------------------------------------------------------------------------------- Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1

[simonmichal]

Hi guys,

I do agree that this would give our project a nice touch :-)

IMHO it would be enough to do a CMake module, but if there is a strong desire to use pkg-config it's also OK with me ;-)

@bbockelm : would you be so kind to prepare a PR? ;-)

Cheers,
Michal

[ljanyst]

I actually wrote one when I started writing the client. It's extremely simplistic and adding COMPONENTS support and plugin suffixes would be a nice touch :)

https://github.com/ljanyst/xrdclient/blob/master/cmake/FindXRootD.cmake

[bbockelm]

Yeah - I think that one might have even been the one I originally forked a few years ago (and have copy / pasted ever since)! Here's the latest revision on my end:

https://github.com/bbockelm/xrootd-multiuser/blob/master/cmake/FindXrootd.cmake

@simonmichal - I'm starting to think what a PR would look like. One big conceptual question: do we want the COMPONENTS arguments of the macro to map to source code components (OFS / ACC / XRDCL etc) or packaging components (SERVER / CLIENT / CORE / PRIVATE)?

The former would likely be more meaningful to developers, as they are likely looking at the source code. The latter would help us stay sane (less components!) because it would better match the existing packaging structures.

Just for reference - here's the upstream docs: https://cmake.org/Wiki/CMake:How_To_Find_Libraries. Seems that there's a reasonable set of helper macros we can either use directly or copy/paste (probably the latter, given the vintage of CMake we use...).

Note: I'm on vacation for approximately the next week - may be a bit before I can return to this.

[simonmichal]

@bbockelm : good question. If we go for source code, we will end up with about 19 components, which is a lot ;-) On the other hand, if we go with packaging we will have about 4, which sounds to me much more sane ;-) I don't think there is much harm in grouping several source code components into a single cmake component. In the worst case cmake will set more variables than the developer needs, and that's it.

[bbockelm]

Although - if we want to do the "more sane" option (which I would like!), what's the correct value of ${XROOTD_SERVER_LIB}.

That would evaluate to something like -lXrdServer -lXrdHttp-4 -lXrdSomethingelse - i.e., listing all the libraries in the server package. Is the linker smart enough to skip unnecessary links? If not, that might force us to do all 19 sub-components.

[simonmichal]

That's a good point. When I wrote my previous comment what I had in mind was INCLUDE_DIRS : |
I have to think it through.

[simonmichal]

I suppose if we use -Wl,--as-needed then we should be OK with the "more sane" option.

[simonmichal]

@bbockelm : are you still interested in implementing the cmake/ pkg-config modules?

[bbockelm]

Hi @simonmichal -

I'm still interested in seeing this -- but at this point, I think I must admit defeat and say I don't have time to do it myself.

So, feel free to keep it open if it's worthwhile to reassign elsewhere... otherwise, maybe just close it for now?

Brian

[simonmichal]

@bbockelm: I pushed following commit 43124f7 that is an attempt to implement a XRootD find module. Let me know if you have any comments!