AlexandreRouma / SDRPlusPlus

Cross-Platform SDR Software

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Building on Linux/BSD Instructions Clarifications/Corrections

rogerxxxx opened this issue · comments

Some minor improvements/corrections within the Linux/BSD manual build instructions, and likely Windows build instructions as well.


MISSING DEPENDENCIES
On Void Linux, the following packages are also required and/or not automatically pulled in by other *-dev packages:

alsa-lib-devel
jack-devel
pulseaudio-devel

Distributions sometimes may or may not mark these as other dependencies of *-devel packages.  Fallback, most developers just need to perform some additional research via their package manager, but should likely be added to the instructions dependencies list for simplifying building.


CMAKELISTS.TXT OMITS INSTALL DIR AT TOP?
Seems CMakeLists.txt omits the install location (eg. PREFIX) definition from the top of the file, later within the middle statically setting to /usr/local.  No big deal for me, and most others, but some might want /home/username/src/sdrpp-git or something else.

CMAKELISTS.TXT FILE NOT MENTIONED
Within "Select which modules you wish to build" section, denote top/root dir CMakeLists.txt as the file to edit, for selecting or deselecting drivers/modules needed or not needed.  Also mentioned, there maybe some drivers built by default, for which the user may not have/own the hardware.

One driver also requires a development package not included on some Linux distributions.  The following will disable hardware requiring external drivers or external development software:
-option(OPT_BUILD_AIRSPY_SOURCE "Build Airspy Source Module (Dependencies: libairspy)" ON)
+option(OPT_BUILD_AIRSPY_SOURCE "Build Airspy Source Module (Dependencies: libairspy)" OFF)
-option(OPT_BUILD_HACKRF_SOURCE "Build HackRF Source Module (Dependencies: libhackrf)" ON)
+option(OPT_BUILD_HACKRF_SOURCE "Build HackRF Source Module (Dependencies: libhackrf)" OFF)
-option(OPT_BUILD_PLUTOSDR_SOURCE "Build PlutoSDR Source Module (Dependencies: libiio, libad9361)" ON)
+option(OPT_BUILD_PLUTOSDR_SOURCE "Build PlutoSDR Source Module (Dependencies: libiio, libad9361)" OFF)

The above are likely pieces of hardware, either original/past or current develops have, and probably should be disabled by default for easy error free initial building.  Shrugs, suggestion.  PlutoSDR ad9361, I do not think most will have a ad9361 2G/3G transceiver, and this only breaks the initial compile with an unresolvable build error until cmakelists.txt is edited or people find the missing dev package not usually readily available.


CHANGE TO UPPER/ROOT DIR BEFORE RUNNING  CREATE_ROOT.SH/CREATE_ROOT.BAT
The build instructions also omit changing to the upper directory prior to running ./create_root.sh script, after building from a sub-directory.  For most developers, most developers inherently understand the script is likely within the main/root directory, however still implied instruction or minor grammatical improvement. Likely both Windows and Linux/BSD instructions.

-- Create a new configuration root directory
-- ./create_root.bat
++ Create a new configuration root directory
++ From the root/main directory of sources, execute:
++ ./create_root.bat

-- Create a new root directory
-- sh ./create_root.sh
++ Create a new root directory
++ From the root/main directory of sources, execute:
++ sh ./create_root.sh


EXPLAIN THE DIFFERENCES BETWEEN ROOT/ AND ROOT_DEV
Also add an additional note somewhere within this section, explain there are two root/ and root_dev/ directories, the initial root/ directory is the default root directory shipped with the sources, root_dev/ directory a copy created by create_root.sh (create_root.bat) for your editing. 


JSON FILE EDITING, ADDING MODULES, SYNTAX
Add an additional note just prior/after to the find/sed/grep incantation, ensuring the formatting of the editing of the JSON file is correct, else will be  deleted.  The last module line printed to stdout by the incantation should not have the additional line ending comma, else the config file will be deleted.


SDRPP AUTOMATICALLY DELETES CONFIG FILES
The program sdrpp already prints the config file(s) error to stdout, and at this point sdrpp should break/stop awaiting correction from the user.  And if all else fails, explicitly letting the user simply manually remove the configuration directory/file, letting sdrpp recreate the files.  But only after the end-user manually requests this action.  Most, if not all other Linux/Unix programs perform similarly.  (eg. $HOME/.vimrc, $HOME/.gvimrc, ...)  I'm guessing, too many bug reports with sdrpp silently not starting within graphical desktops?  If so, simply adding a graphical prompt with the stdout error should suffice.  (eg. For example, edit $HOME/.gvimrc with incorrect syntax error and start gvim from a graphical interface.)


OK, looks like I'm up and running sdrpp without having to install to /usr (or /usr/local) dir!  However, will likely sooner or later do so, as all this editing is tedious.

On Void Linux, the following packages are also required and/or not automatically pulled in by other *-dev packages:

alsa-lib-devel
jack-devel
pulseaudio-devel

You don't need the development files for these library to compile or run SDR++...

CMAKELISTS.TXT OMITS INSTALL DIR AT TOP?
Seems CMakeLists.txt omits the install location (eg. PREFIX) definition from the top of the file, later within the middle statically setting to /usr/local. No big deal for me, and most others, but some might want /home/username/src/sdrpp-git or something else.

This is just inexperience with cmake, see https://cmake.org/cmake/help/latest/variable/CMAKE_INSTALL_PREFIX.html

CMAKELISTS.TXT FILE NOT MENTIONED
Within "Select which modules you wish to build" section, denote top/root dir CMakeLists.txt as the file to edit, for selecting or deselecting drivers/modules needed or not needed. Also mentioned, there maybe some drivers built by default, for which the user may not have/own the hardware.

YOU SHOULD NEVER EDIT THE CMAKELISTS.. I REPEAT, DO NOT EDIT THE CMAKEFILES. This is again basic cmake usage that you don't seem to have. It's even explained in the readme here with the table of options being here.

One driver also requires a development package not included on some Linux distributions.

Then just disable it...

The above are likely pieces of hardware, either original/past or current develops have, and probably should be disabled by default for easy error free initial building. Shrugs, suggestion. PlutoSDR ad9361, I do not think most will have a ad9361 2G/3G transceiver, and this only breaks the initial compile with an unresolvable build error until cmakelists.txt is edited or people find the missing dev package not usually readily available.

Really? These are some of the most common SDRs in use today. All of these modules are enabled by default because most distros have the dependencies for them readily available and uses will trivially be able to make a complete build of the software. Again, if you don't have these devices and you don't care about still having the modules for them, just disable the build using the options listed in the readme.

EXPLAIN THE DIFFERENCES BETWEEN ROOT/ AND ROOT_DEV
Also add an additional note somewhere within this section, explain there are two root/ and root_dev/ directories, the initial root/ directory is the default root directory shipped with the sources, root_dev/ directory a copy created by create_root.sh (create_root.bat) for your editing.

Its name and context in the readme makes this self explanatory... Additionally, knowing what the root directory does is not a requirement for just running the app. The readme is not supposed to be documenting the internals of the software.

The last module line printed to stdout by the incantation should not have the additional line ending comma, else the config file will be deleted.

This is basic JSON syntax.
As I already told you in the other issue (thanks for making me repeat myself), users should not be editing config files manually.

By the way, thanks for the giant code block and three screens wide lines, really makes things nice and hard to read.