Comments (5)
@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.
from limesuite.
- works on gcc, any remaining issues will involve supporting shared on MSVC is that is ever desirable.
from limesuite.
Related Issues (20)
- UE's can't connect to LimeSDR on a bandwhith 1,4Mhz HOT 1
- Docs incorrect for LMS_Calibrate
- 22.09.0 build issue when Connection Remote is enabled. HOT 4
- The port is busy. Connection LimeRFE + LimeSDR HOT 1
- Build Windows assets for 22.09 release
- Issue with Debian packages. HOT 4
- Issue with rv64 HOT 6
- lime::ADF4002 infinite loop
- how can I access LMS7002M's register directly
- LimeUtil --fpga requires hard resetting the device (LimeSDR Mini V2) HOT 1
- Make a new Lime Suite release. HOT 1
- RPM Package for Fedora
- Firmware missing upstream HOT 5
- LimeSuiteGUI not built HOT 1
- fix API functions LMS_StartStream() and LMS_StopStream() : HOT 1
- Make LimeSDR Mini 2.0 Rx-only behaviour the same as previous SDRs. HOT 2
- About the latest release HOT 2
- LimeXTRX on PCIe - `basicTx` Issues After LimeSuite Update HOT 3
- limesuite and gr-limesdr HOT 1
- USB draw current to stays high after example's exit (which is not good)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from limesuite.