Date
1 - 20 of 46
cmake re-work (for linux, macOS, windows)
|
rainbow@...
Good morning,
I am doing a full rework of cmake scripts on SDRangel to support multi-platform and auto packaging with dependencies discovery. The work can be seen at [1]. The objective will be to distribuite SDRangel with linux distribution (so no internal auto-build external dependencies). Main Changes: - remove all qmake project scripts - unify plugins and pluginssrv in a unique tree to easily manage the changes; pluingssrv is a link to plugins (works on windows too) - rewrite plugins discovery to be compliant with Qt5 (sdrbase/plugin/pluginmanager.cpp) - works on cmake options; see later - remove udev rules (they are not SDRangel relevant but device driver dependant) - remove all external packages; see TODO - the project version is defined only on CMakeLists.txt - organize folder disposition; see TODO - use lib/sdrangel as library/plugins destination; avoid confusion in lib/ - if plugins are not found print an alert (avoid segmentation fault) - rebuild the logo in svg and use high resolution for desktop app - use cpack to build packages - use travis-ci as continuous integrator (with linux and macos); can be used to track -dev dependencies - `make` and `make install` link correctly Options: - use CMAKE_BUILD_TYPE to define build type - use Qt5_DIR if you want to define where Qt5 reside - use CMAKE_INSTALL_PREFIX to define where to install the application - use BUNDLE=1 to build package, .deb or .dmg based on platform. - for the others see CMakeLists.txt Platform dependent: * Linux: - build deb package (for the moment on /usr/local); see TODO - build rpm package; need dependencies list and more tests; probably we need to move on tools distro specific like debian. * macOS: - fixed many bugs to build SDRangel on macOS < 10.12 - upstream all dependencies to macports: perseus-sdr, codec2, dsdcc, mbelib, cm2566cc. SDRangel will be there when I receive your feedback. - correctly build .app and .dmg with `make package` - as a bonus you can find a full dmg built with macOS 10.11 with all dependencies at [2]. try it ;-) * Windows - I did a build with mingw64 and it works - use external/windows as git submodule to maintain binary libraries so you need to clone the repository with `git clone --recursive <project url>` or initialize the submodule TODO: - check on start if the build cpu flags are supported otherwise stop the program and print an alert, avoid segmentation fault - move from cpack to debian/ (debhelper) as discussed yesterday with a cmake developer - conclude windows build with correct dependencies and manage packaging with cpack; - enable travis-ci for windows and use chocolatey to manage dependencies - maybe try to build with MSVC if performance are better - discuss on ExternalProject and how can be used to build and manage external dependencies; used only on request though cmake option - macOS signature should be implemented but I don't have a subscription to Apple developer program Probably I lost something :) Anyway, any help or comments will be appreciate. /davide [1] https://github.com/ra1nb0w/sdrangel/tree/cmake [2] https://www.icloud.com/iclouddrive/026ntpbCefNu_D5UxEZ5DxL7w#sdrangel-4.8.0-aac8a64_10.11
|
|
|
|
Hi Davide, I am not against changes but taken as-is these are massively breaking changes. It would at least need to be phased in consistent blocks. Among other things I have already spotted issues: - I use MSVC for Windows and not mingw AFAIK these are not interchangeable - The localinput plugin does not need cm256cc I am sure there are many more issues therefore a staged approach is a must. Having said that I value your work and consider it quite interesting. Brgds Edouard
On Fri, May 17, 2019, 11:09 Davide Gerhard via Groups.Io <rainbow=irh.it@groups.io> wrote: Good morning,
|
|
|
|
Joe Puma
Can SDRangel be ran on a Raspberry Pi?
toggle quoted messageShow quoted text
On May 17, 2019, at 8:06 AM, Edouard Griffiths <f4exb06@...> wrote:
|
|
|
|
I do not see the connection with Raspberry Pi and although I would advise you to open a new topic I can briefly say that generally it will work better on an armv8 distribution (try Arch). You can forget about the GUI flavor but the server variant works very well.
Brgds, Edouard.
|
|
|
|
Michael Durkin
will run on Atomic-Pi
On Fri, May 17, 2019 at 8:54 AM Edouard Griffiths <f4exb06@...> wrote: I do not see the connection with Raspberry Pi and although I would advise you to open a new topic I can briefly say that generally it will work better on an armv8 distribution (try Arch). You can forget about the GUI flavor but the server variant works very well.
|
|
|
|
As a first superficial tour:
- remove all qmake project scripts: > why not. If there are better options. I am not a fan of .pro files... - unify plugins and pluginssrv in a unique tree to easily manage the changes; pluingssrv is a link to plugins (works on windows too) > if a symbolic link is necessary I don't see the point. I don't mind selecting GUI or server build at cmake time if this is the case. In most situations one would chose one or the other - rewrite plugins discovery to be compliant with Qt5 (sdrbase/plugin/pluginmanager.cpp) > I have seen the code. Apart from cosmetic changes this seems fine. To be tested in all situations. This can be done idependently and maybe quite soon actually since I am already doing a lot of changes in the Plugin Manager to support MIMO devices - works on cmake options; see later > Yet to be seen - remove udev rules (they are not SDRangel relevant but device driver dependant) > this statement is only partially true. The application depends on the host library that depends on the firmware that eventually may impact the udev rules. I do not see the point in removing this. Moreover I have spent a lot of time investigating on how to implement these rules without the need to reboot or log in / log out (see install.sh) - remove all external packages; see TODO > Not sure about this. I find it more practical to bundle everything together than having package dependencies. - the project version is defined only on CMakeLists.txt > I have to check this. Not sure what this implies. - organize folder disposition; see TODO > same as above - use lib/sdrangel as library/plugins destination; avoid confusion in lib/ > I might not agree with this. putting the plugins in a 'plugins' structure organize things better - if plugins are not found print an alert (avoid segmentation fault) > Why? Not all plugins are built necessarily. - rebuild the logo in svg and use high resolution for desktop app > Probably good - use cpack to build packages > Don't know about 'cpack' - use travis-ci as continuous integrator (with linux and macos); can be used to track -dev dependencies > Can be desirable indeed. A first failed attempt was made to build with Travis for Windows. - `make` and `make install` link correctly > Not sure about what this covers Brgds, Edouard.
|
|
|
|
Davide Gerhard <rainbow@...>
On Friday, 17/05/2019 14:06 CEST, Edouard Griffiths <f4exb06@gmail.com> wrote:
Hi Davide,Probably I was too concise but I didn't want to annoying with details. Was an introduction and to start a discussion about the topic. I am not against changes but taken as-is these are massively breakingSure, I though a lot on how to merge these changes and this is why I posted here before PRs. The PRs can be divided in two areas: - bug fix on the code or enhancement as plugins management - new cmake platform The first point can be sent as always, divided in chunk/argument, but the last (cmake) will be breaking and there is no way to avoid that; this is way I sent this e-mail, without too much commits squashing/clean-up, but to discuss/understand the features needed and ask to everyone to build/install/package with that branch. other things I have already spotted issues:Probably, I didn't underline enough that Windows is WIP and I did only a build test with mingw64, instead of 32bit that it is distribuited, and I saw good improvements in performance (as expected on DSP). Just a note: many and many libraries, included Qt, use mingw as toolchain (as you correctly wrote) so probably use the same toolchain can be a good idea. Why you are using MSVC? removing the obvious reason that it is Microsoft. Are you using to catch bugs? or have you seen performance improvement? - The localinput plugin does not need cm256ccAlready in my TODO list of cleanup (now removed); was a test done on old macOS with some out-of-tree patches that I done. I am sure there are many more issues therefore a staged approach is athis is true for all code and for all developers, so quite pointless as argumentation ;-)
|
|
|
|
Davide Gerhard <rainbow@...>
On Saturday, 18/05/2019 15:53 CEST, Edouard Griffiths <f4exb06@gmail.com> wrote:
As a first superficial tour:Symbolic link is necessary only by cmake to differentiate the build. Probably there is another way to do it without it. I need to investigate. Many times when you distribuite the package, deb/dmg/exe, we need to build both so it is needed. And sometimes it is useful to have both already built and ready to doing tests. Anyway, this "fusion" avoid many mistakes on plugin creation or changes and simplify code study. - rewrite plugins discovery to be compliant with Qt5Yes, as I wrote on the previous e-mail, my idea is to send many PRs with changes about the C++ code and in the meantime work on cmake (disruptive change) - works on cmake options; see laterthe time is not a rational argumentation ;-)Yet to be seen- remove udev rules (they are not SDRangel relevant but device driver Anyway, generally udev rules doesn't need reboot/log-in/out specially on systemd. Yes, I have seen `install.sh` probably can be managed as submodule but they are device related, as you stated, and not SDRangel correlated. My point of view at this stage is from a package maintainer and therefore every package should be standalone and should works fine. From an SDR point, seems to me that Debian/Fedora and newer Ubuntu has "all" device libraries already on repository (except libperseus-sdr) and so we should use that. For other libraries we should package or manage correctly during building. In travis-ci, for example, I do `make` and `make install` for dependencies not already in repository. Anyway, this is the other main point, beyond windows, that I need to understand and complete the implementation (probably using ExternalProject of cmake). - remove all external packages; see TODOthis is clear from your work :)Not sure about this. I find it more practical to bundle everythingtogether than having package dependencies. And sometimes permit more control on the result but to package and maintain the software for long period it is useful to maintain separate software. This is a must if we want to upstream SDRangel to GNU/Linux distribution or in FreeBSD ports. with the previous and this statement I hope I have clarified my point of view. - the project version is defined only on CMakeLists.txtsimplify the version bump without errors or mismatch; moreover manageI have to check this. Not sure what this implies. automatically git commit ecc. not valid for CHANGELOG (my idea is to file it on repository root with the same format) and for headers. - use lib/sdrangel as library/plugins destination; avoid confusion inprobably I wrote bad. the main library (libsdrbase, linsdrgui, ecc.) will be on lib/sdrangel plugins will be on lib/sdrangel/{plugins,pluginssrv} but without all folders like 'channelrx/freqtracker' This is valid only for build not for source. this was done to avoid libsdrbase, ecc. on the main lib/ folder because they are too name generic. this change confinate all libraries/plugins on the same folder (lib/sdrangel); like many others do, wireshark for example. this is a practical example: /opt/local/lib/sdrangel /opt/local/lib/sdrangel/libswagger.dylib /opt/local/lib/sdrangel/libhttpserver.dylib /opt/local/lib/sdrangel/libfcdhid.dylib /opt/local/lib/sdrangel/plugins /opt/local/lib/sdrangel/plugins/libremotesource.dylib /opt/local/lib/sdrangel/plugins/libinputlocal.dylib /opt/local/lib/sdrangel/plugins/libdemoddatv.dylib /opt/local/lib/sdrangel/plugins/liboutputfilesink.dylib /opt/local/lib/sdrangel/plugins/libremotesink.dylib /opt/local/lib/sdrangel/plugins/libinputremote.dylib - if plugins are not found print an alert (avoid segmentation fault)"if no plugins are found" they print an alert; generally this happenWhy? Not all plugins are built necessarily. when it doesn't find the folder. For a user see a segmentation fault is always bad. - rebuild the logo in svg and use high resolution for desktop appprobably?Probably good - use travis-ci as continuous integrator (with linux and macos); canthis will be my next step; with mingw64 and Chocolatey. - `make` and `make install` link correctlywith your cmake `make install` doesn't work correctly neither on linuxNot sure about what this covers nor macOS (linking problem) I hope that this clarify my work and improve discussion. /davide
|
|
|
|
Re mingw vs MSVC: some libraries and more significantly SoapySDR related stuff is MSVC only. This implies dropping a few features in Windows. Why not. I don't care much about Windows anyway.
More on the rest later. Brgds, Edouard.
|
|
|
|
Re plugins / pluginssrv and package build. I don't think it is necessary to package the server flavor. This is advanced usage and could be reached only by compiling the source or building a docker image with the sdrangel-docker project.
Again more on the rest as I think of it... Brgds, Edouard.
|
|
|
|
Re udev rules: OK to remove it. After all SDRangel is addressed to people who are supposed to know what to do with a computer so they can manage this themselves. I know how to do it so it will not change anything for me.
Brgds, Edouard. Note: similarly I think all the python and go stuff should go in its own 'sdrangel-scripts' (for example) repository. Note2: the `udev-rules` folder is now in a safe place
|
|
|
|
Siegfried Jackstien
would be nice if you would care about windoze ... (just a tiny bit ... grin) dg9bfc sigi
Am 18.05.2019 um 17:58 schrieb Edouard
Griffiths:
Re mingw vs MSVC: some libraries and more significantly SoapySDR related stuff is MSVC only. This implies dropping a few features in Windows. Why not. I don't care much about Windows anyway.
|
|
|
|
Re "if no plugins are found": if the software is built properly you would get at least one device plugin of each category: Rx, Tx, (future) MIMO and a few channel plugins of every category also. Therefore I cannot think of a case where you have zero plugins and the software is workable at all.
Brgds, Edouard.
|
|
|
|
"with your cmake `make install` doesn't work correctly neither on linux
nor macOS (linking problem)" What's wrong in Linux (at least)? I routinely build my software without issues.
|
|
|
|
I tried to build from the cmake branch of your fork and apart from a small glitch (with XTRX input) it is clean and works and runs fine apparently. There is only a major regression with sdrangel.rcc disappearing and thus causing the internal server for swagger UI to fail. REST API and its self documentation whether you like it or not is an essential feature. I am surprised because I thought this had been fixed in a previous PR already. The symbolic link pluginssrv to plugins is a small annoyance.
Now the question is: without the .pro files and debian folder how do we build for Windows and Debian? If this can be done totally out of tree the better (not sure this is possible). Not that I am a great fan of building packages anyway but that's a reason to try to make it as automated as possible. Edit: I also noticed that BLADERF_DIR, IIO_DIR and SOAPYSDR_DIR are reported "not used" by cmake. This causes the plugins for BladeRF, Pluto and Soapy to be missing. I think this is just a glitch somewhere. Edit2: I tried to remove pluginssrv symbolic link and (of course changing to plugins at the appropriate place) the GUI and the server can be built separately. This is not an issue because as said earlier one would chose one or the other and there is no need to include the server in a package distribution. Brgds, Edouard.
|
|
|
|
Andre Neitzel
>>>>> - as a bonus you can find a full dmg built with macOS 10.11 with all dependencies at [2]. try it ;-) thanks for provide a ready to go DMG for MAc. I tested it and it works with RTL-SDR stick, but if i use HackRF its not able to start sample source (HackRF board is seen by SDRangel and choosable in GUI, but after klick on start a error "can not start sample source" appears). Dont know why this happen... maybe something is missing? regards André Am Fr., 17. Mai 2019 um 11:09 Uhr schrieb Davide Gerhard via Groups.Io <rainbow=irh.it@groups.io>:
Good morning,
|
|
|
|
Same here, looks good, runs fine with BladeRF Micro but says ""can not start sample source" Also I'm having the same problem as with the Sigi's builds, audio stutters when moving mouse over the SDRAngel window. 73!
On Mon, May 20, 2019 at 7:23 AM Andre Neitzel <andreneitzel.mobil@...> wrote:
--
LU5AGQ Gaston Ettedgui .-.. ..- ..... .- --. --.- lu5agq@... http://www.digimodos.com http://ar.groups.yahoo.com/group/LU-APRS http://ar.groups.yahoo.com/group/DSTARLU
|
|
|
|
Davide Gerhard <rainbow@...>
Sorry for the delay, I was at BSDCan.
Please, avoid cross/multiple-posting otherwise is quite hard to move on (see netiquette). Maybe maintain a queue of answers and then write a single email answering after each point. I prefer "describe --abbrev=7 --always --tags" thus you get athe version declared on CMakeLists.txt must be equal to the tag. Now the result (used also in the application) is "4.8.0-b0b646fa0" if the build come from git otherwise only the version. What do you want to use that string? The important addition is number of commits? ps. yes github short to 7 but generally is between 7 and 9; see variable `core.abbrev` on git-config(1) Re mingw vs MSVC: some libraries and more significantly SoapySDRI can write to SoapySDR developer and ask to him why he using MSVC. Anyway, why I can't use mixed build library? Except that sometimes arise trouble on linking (and they are not so easy to trace). Have you notice that? Re "if no plugins are found": if the software is built properly youAs I said, the problem is not the build. It is when you install and the binary doesn't find the plugins. Plugins are optional by definition and good programming need to account it. Moreover, adding one `if` is not so bad ;-) I think that it is worse a segmentation fault without a message; in this way if happen, the user can send it to developers. I tried few times in linux and macOS and linking during `make install`" with your cmake `make install` doesn't work correctly neither onWhat's wrong in Linux (at least)? I routinely build my software doesn't work correctly between SDRangel libraries. There is only a major regression with sdrangel.rcc disappearing andrcc should binary internal and now it is, throw `CMAKE_AUTORCC`. I tested both, sdrangel and sdragenlsrv, http server and I see correctly HTML2 documentation and Interactive Swagger. Can you provide the link or more instruction on how to verify this behaviour? Now the question is: without the .pro files and debian folder how doas I said few times, Windows is WIP and the final package will be built with `make package` as macOS; Debian .deb and Fedora .rpm are now using the same system but one cmake developer said me to move to distribution tools, like debhelper. So now I create debian/ and then I will see how Fedora package tool works. I also noticed that BLADERF_DIR, IIO_DIR and SOAPYSDR_DIR are reportedI didn't touched cmake/Modules/Find* so it is strange; except SoapySDR because I need extra info like version. Can you provide a usage example because I see BLADERF_DIR and IIO_DIR in Find*. Anyway, generally this is not good way to declare/use library; you should provide *_INCLUDE and *_LIBRARY as package manager do. I tried to remove pluginssrv symbolic link and (of course changing toIt is wrong to avoid both. I fixed the problem without symbolik link. Note: similarly I think all the python and go stuff should go in itsI am not sure about this; those python scripts are useful to SDRangel; do should packaged with sources. In the end: are you agree with splitting in two main phase? 1) send general code fixes through PR 2) when cmake is fully working on all platforms replace the old one. thank you /davide
|
|
|
|
Davide Gerhard <rainbow@...>
On Saturday, 18/05/2019 21:11 CEST, Siegfried Jackstien <siegfried.jackstien@freenet.de> wrote:
would be nice if you would care about windoze ... (just a tiny bitfrom my point of view it's a must. ps. I don't like windows too ;-)
|
|
|
|
Davide Gerhard <rainbow@...>
On Monday, 20/05/2019 12:23 CEST, Andre Neitzel <andreneitzel.mobil@gmail.com> wrote:
thank you for testing the image!all dependencies at [2]. try it ;-)- as a bonus you can find a full dmg built with macOS 10.11 with Can you run from console and see what happen? if you open the dmg, you can run SDRangel with /Volumes/sdrangel-4.8.0-aac8a64_10.11.6_x86_64/SDRangel.app/Contents/MacOS/SDRangel are you using macports? if yes, you can install all dependencies, like cm256cc, and use my tree to build the code and see if it works? thanks /davide
|
|
|