Not sure how to link a common lib that is built separately

[ethanbb]

I'm trying to set up a situation where I build a common library using CMake from one repository, then build two plugins from other repositories that need to link this library.

I know that in order to pull in the library header, I have to have the library repository as a parallel directory to the others and use target_include_directories to point CMake to the library Source folder. That's fine although a little inelegant.

However, when building the library (on Windows), the common lib CMake script only copies the .dll to the shared folder, which is where I was trying to find the library in order to link it. I think I need the .lib instead, but that's not installed, but buried in the library Build folder under an arbitrary subdirectory. I could just assume it's Build/VS2013, and then Linux and Mac might be able to link from what's in the shared folder instead. Not sure if this is what you intended or if there's a better way in the works though.

Thanks by the way, I was skeptical at first but I think this CMake system could make it a lot easier to manage several plugins with independent development timelines, rather than keeping them all in one repository like we've been doing.

[aacuevas]

I was wondering how long it would take to anyone to notice this ;)

Indeed, there is no good way to link to external common libraries yet. But since the only commonlib we actually use is for the hdf5 plugins, and it's already integrated with the plugins, I preferred to get everything online to get it testing.

My current plan for this involves installing both the headers and the required lib files into the main GUI tree of the development machine, so plugin build projects can find them easily and as automatically as possible.

[ethanbb]

OK, that would be great to eventually install the headers and .libs!

Anyway, there's no real rush on our end; I just wanted to try the new system.

[ethanbb]

In case you're interested, I managed to install a library from one repository and link a plugin in a different one to it on Windows and Linux (and I made a guess for macOS, but it's not tested). There was lots of trial and error, so maybe I can spare you some of that by showing you what I ended up with.

The library CMakeLists.txt is here: https://github.com/tne-lab/OpenEphysFFTW/blob/master/OpenEphysFFTW/Build/CMakeLists.txt

and the plugin: https://github.com/tne-lab/phase-calculator/blob/cmake/PhaseCalculator/Build/CMakeLists.txt

Some details:

• The public header from the library gets installed into a folder include which is next to shared.
  • Maybe suboptimal: I went with manually specifying which header to install in the CMakeLists.txt file. Maybe there's a way to indicate that through the source directory structure instead?
• The .lib on Windows goes into a folder lib also next to shared (i.e. within bin). This allows CMake to find it by adding the bin directory to CMAKE_PREFIX_PATH.
• For Linux and Mac, the shared folder gets set to CMAKE_LIBRARY_PATH so it can be linked from.
• The most obscure/frustrating bug was, I found that on Linux (Ubuntu 18) I had to change the -rpath,'$$ORIGIN[/../shared]'" linker flags to $ORIGIN... i.e. one dollar sign. I think the two dollar signs is a Makefile thing that CMake doesn't require, and when linked with the two dollar signs, the plugin library couldn't find the shared library at runtime.
  • This seems like an issue with all the CMakeLists.txt currently on here. Have you tested on Linux/if so have you run into this issue?

[aacuevas]

Thanks!
This is basically my general idea.

Right now I'm also moving the main GUI build to CMake, which will allow greater flexibility and use of automated build systems. However, that means that I will be making some changes to the GUI folder structure, so I am keeping making a proper commonlib install structure on hold until that is finished,

Also, thanks for noticing the $ORIGIN issue. Ubuntu 16 (which I use for testing) and 18 have different linkers, with 16 using the rpath in the main GUI and 18 the one in the plugins, so this error was not triggering yet in my machine. I'll get it fixed.

[aacuevas]

This should be fixed with the current versions (which, by the way, only work with the newer CMake-based builds of the GUI, currently in development). When installing a common lib it will install a copy of the relevant files inside a "installed_libs" subdirectory of the GUI base directory, with plugins already configured to look there.

Calling find_library and target_link_libraries for the commonlib in the plugin CMakeLists.txt, as any other lib (but without the need for the includes) should automatically detect it.

If you could check the new structure with your plugins to check if it might need some tweaks I would appreciate it. Thanks!

[ethanbb]

OK thanks, I'll try it out sometime this week.

I guess I'll have to make a push to start using CMake for all the TNE lab's Open Ephys stuff. It's definitely cleaner for plugin development and I want to be using it for that going forward, but I didn't realize CMake plugins would also only work with a CMake GUI. The timing's also a bit weird for me as I'll be leaving the lab in a couple of weeks. But I do want to make the switch and keep up with the direction of future development, so I'm really hoping there won't be too many hitches and we can get the full CMake system running smoothly by that point.

@markschatza FYI, we should make sure to coordinate in the next couple of weeks so that we can get CMake working for everything without breaking things.

[aacuevas]

It is not that they require necessarily a GUI built by CMake, but we are treating this repositories as part of the "development" branch still, they might have had issues with master since the start, as we already had some changes in effect. And we just pushed the CMake GUI to development, so along that we changed the paths of the templates to reflect the new folder structure.

Building the GUI with CMake should be fairly straightforward, just run CMake inside the Build folder. We have updated the instructions on the wiki. We have also slightly modified the plugin template so cmake is run from the Build folder instead of having to create multiple directories, since every developer will only create files for their OS, it seemed redundant otherwise. Again, everything in the wiki has been updated, if you have any issue you can just contact me.

[ethanbb]

Unfortunately, setting the CMAKE_PREFIX_PATH based on the config type and using that to find the correct version of the library in find_library doesn't seem to work on Windows. All configurations end up linking to the release version of the common library. My understanding is that generator expressions aren't supported in find_library, and probably it just searches once, using Release for the config, and then uses that for everything. (Somebody seems to have run into a similar issue here.)

Looks like using an "imported target" for the common libraries may be a better way. I'll try it out and report back...

[aacuevas]

Oh, that is true, a mistake on my part...

Thsi would be much easier if we were not constrained to 3.5, as newer versions include functionalities that could help solve this (like target_link_directories or support of generator expressions for link_directories)

imported targets could be an option. I have another idea which should work, using the ability of target_link_libraries to link different libs for debug and release modes.

[ethanbb]

OK, I got something to work on Windows (haven't tested on Linux yet). Here it is: https://github.com/tne-lab/phase-calculator/blob/cmake/PhaseCalculator/link_open_ephys_lib.cmake

[ethanbb]

Using target_link_libraries in the way you suggest could work, but it seems more limited because then you couldn't link to different versions for other configurations like RelWithDebInfo (if I understand correctly).

[ethanbb]

Testing on Linux and encountered another issue I saw before when trying to use find_library - CMake automatically prepends lib to the name when searching and doesn't find the library if it doesn't have that prefix. My solution at the time was to get rid of set(CMAKE_SHARED_LIBRARY_PREFIX "") for common libs. Did you run into this @aacuevas?

[ethanbb]

Also just a reminder that $$ORIGIN is still an issue here and in the OEPlugin repo.

I can make a PR with the easy fixes - mainly CONFIGURATIONS and this rpath thing. Maybe we should discuss the issue with linking multiple configurations further, though.

[cjthomas-opensource]

I'm beating my head against a wall with similar issues. Ethan's code helped. Still trying to figure out where the "lib" prefix issue I'm having is coming from. Details were sent to Josh via email.

I'm splitting out two utility libraries from a plugin I've been writing, as they'll be useful for other projects (my own and other labs'). Being able to properly build and use common libraries is an important feature, unless you want copy-pasted code everywhere.