Topics

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


Edouard Griffiths
 

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,

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




Joe Puma
 

Can SDRangel be ran on a Raspberry Pi?


On May 17, 2019, at 8:06 AM, Edouard Griffiths <f4exb06@...> wrote:

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,

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




Edouard Griffiths
 

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.
Brgds, Edouard.


Edouard Griffiths
 

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 breaking
changes. It would at least need to be phased in consistent
blocks. Among
Sure, 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:
- I use MSVC for Windows and not mingw AFAIK these are not
interchangeable
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 cm256cc
Already 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 a
must.
this 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:

- 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
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 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
Yes, 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 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)
the time is not a rational argumentation ;-)
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 TODO
Not sure about this. I find it more practical to bundle everything
together than having package dependencies.
this is clear from your work :)
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.txt
I have to check this. Not sure what this implies.
simplify the version bump without errors or mismatch; moreover manage
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 in
lib/
I might not agree with this. putting the plugins in a 'plugins'
structure organize things better
probably 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)
Why? Not all plugins are built necessarily.
"if no plugins are found" they print an alert; generally this happen
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 app
Probably good
probably?

- 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.
this will be my next step; with mingw64 and Chocolatey.

- `make` and `make install` link correctly
Not sure about what this covers
with your cmake `make install` doesn't work correctly neither on linux
nor macOS (linking problem)

I hope that this clarify my work and improve discussion.
/davide


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.
More on the rest later.
Brgds, Edouard.


Edouard Griffiths
 

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.


Edouard Griffiths
 
Edited

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.
More on the rest later.
Brgds, Edouard.


Edouard Griffiths
 

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.


Edouard Griffiths
 

"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.


Edouard Griffiths
 
Edited

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,

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




Gaston LU5AGQ
 

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:
>>>>> - 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,

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






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 a
reference to the latest tag, the number of commits since as the patch
number and the commit SHA1 first 7 characters (I think Github
abbreviates it to the first 7 characters). For example:
"v4.8.0-25-g8fd864a"
the 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 SoapySDR
related stuff is MSVC only. This implies dropping a few features in
Windows. Why not. I don't care much about Windows anyway.
I 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 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.
As 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.

" 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 few times in linux and macOS and linking during `make install`
doesn't work correctly between SDRangel libraries.

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.
rcc 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 do
we build for Windows and Debian? If this can be done totally out of
tree the better
as 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 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
I 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 to
plugins at the appropriate place) the GUI and the server can be built
separately.
It 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 its
own 'sdrangel-scripts' (for example) repository.
I 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 bit
... grin)
from 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:

- 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?
thank you for testing the image!

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