lime-suite development library: build shared library about limesuite HOT 5 CLOSED

@rjonaitis I was thinking about taking care of this and I want to run this by you. Currently we build a lot of little static libraries and link them together. Also the GUI code is linked together with the non-gui code. Ideally these would be separate libraries and the Lime suite could be compiled without GUI libraries. So I want to propose the following without drastic changes to the organization of the repo, mostly just CMake changes:

The top level src/CMakelists.txt would contain the following sections:

• A list of all non-gui source files. This includes LMS7002M sources, connection registry, and device specific files like Si5351C/, ADF4002/
• include_directories() for all non-gui directories with library headers that will be installed
• A library build/install command to build the target limesuite.dll / liblimesuite.so Ideally, this will be a shared library.
• include subdirectories with their own CMakeLists for various built-in connections (STREAM, COM, Novena) These build their own modules that link against liblimesuite
• A list of all gui source files.
• include_directories() for all gui directories with headers for the GUI executable
• An executable target for the lms7suite.exe that links against liblimesuite

And most of the subdirectories CMakeLists.txt would be removed by this work.

Thoughts?

from limesuite.

That's a good idea, I too was thinking of making one single library. As the requests come up to integrate LMS7002 controls into other packages, it becomes clear that they going to need the whole lms7suite functionality, not just a subset of it as I previously expected.

Of course it would be nice to have option to also link staticaly, at least for Windows to simplify distribution to single binary file.

Classes and functions in the shared library will need an export macro, example here (works windows and unix): https://gcc.gnu.org/wiki/Visibility

I see this is mainly oriented towards GCC, need to make sure this will be compatible with Visual C++ compiler, because now on Windows lms7suite is dependent on CyAPI library which is available only for visual c++.

from limesuite.

Of course it would be nice to have option to also link staticaly, at least for Windows to simplify distribution to single binary file.

We can just do add_library(...) without specifying SHARED or STATIC. This will default to static unless -DBUILD_SHARED_LIBS=ON is passed to cmake.

I imagine that this lime-suite will become some kind of build/development package for users (even windows users) with headers, .libs, .dlls, cmake config files, documentation, modules for devices. In any case, we may want to build both shared and static, and ship both with the installer.

I see this is mainly oriented towards GCC, need to make sure this will be compatible with Visual C++ compiler, because now on Windows lms7suite is dependent on CyAPI library which is available only for visual c++.

The visibility flags are gcc specific, but the import/export macros in the example are basically a cross platform way to declare library symbols and support static and shared as well.

Example

//code before
class LMS7002M
{

};

//code after
#include <lime/config.h>

class LIME_API LMS7002M
{

}

config.h defines LIME_API to nothing when we build static, dllexport when we build a dll, and dllimport when we link client code. config.h also has common build constants, macros, version info. I use this paradigm all the time, example: https://github.com/pothosware/SoapySDR/blob/master/include/SoapySDR/Config.h

from limesuite.

• 4c2bd9a

from limesuite.

• works on gcc, any remaining issues will involve supporting shared on MSVC is that is ever desirable.

from limesuite.