If this will provide some sort of help, here’s what SDRAngel does for FreeDV (but Edouard doesn’t use GNURadio as the basis for his code):
sudo apt-get -y install libspeexdsp-dev libsamplerate0-dev
cd /opt/build
git clone https://github.com/drowe67/codec2.git
cd codec2
git reset --hard 76a20416d715ee06f8b36a9953506876689a3bd2
mkdir build_linux; cd build_linux
cmake -Wno-dev -DCMAKE_INSTALL_PREFIX=/opt/install/codec2 ..
make -j $(nproc) install
For what it’s worth…And - for now - I’m back using SDRAngel until this can get sorted out and documented in a way that it compiles clean for Qradiolink.
Marty, thank you for the suggestion. That is of course one way of doing things, and it works. But unfortunately it tends to lead to more fragmentation instead of less, and towards “maintaining” in a certain sense several upstream dependencies. I have done this in the past, and it is not sustainable long term for a project with limited manpower. I will not pursue this path, and instead I will try to work towards including the software in packages for Linux distributions, which should trickle eventually downstream to users.
There is nothing wrong with building software for your own use from source. I have been a user of both Slackware and Gentoo in the past, where such a thing is common. It is indeed necessary up until a certain stage in developement where code quality reaches a good enough level to match the QA requirements of a distribution. But it is not desirable from a maintainers point of view.
There is one other way you can do this that you have complete control and no one has to compile the code…Make the QRadiolink app a ‘Docker-ized’ image and let the masses install it that way. Then everyone gets the same results because it’s from your Docker image. SDRAngel is distributed that way, too.
Marty, yes, that could be a way forward, even if only for short term. Perhaps Docker is a little overkill, perhaps app-image or similar. I’ll look into it.
Anyway, some steps I took recently make it just a little more probable for a Windows port to exist in the future.
Andrew, that’s also a valid way forward. My problem currently is that my dev laptop is an old 32 bit system so I can’t use that to build packages and can’t/won’t upgrade or use my other hardware for different reasons (lack of time for new install mainly).
I’d like to set up a virtualized environment (perhaps Jenkins/Travis powered) for CI builds and an automated QA suite. Right now Travis CI only checks succesful build and deploys Debian archives if a new Git tag is detected. Any QA engineers with expertise in automating tests for user facing programs can chime in with ideas if they want.
I’m also working a bit behind the scene towards getting the package included in mainline Debian so this could trickle downstream to other distros based on it. But good QA is paramount for that. I don’t like buggy packages in my stable system and neither should anyone.
