PyBOMBS is _supposed_ to make compiles easier, but is definitely not required. Many people find it easier to build a subset of the GR ecosystem without it, and there are build scripts out there that build up a few things (given that you've already installed all the deps). We'll keep working on making it easier to use. PyBOMBS has a little bit of a challenge, in that it tries to be a dependency manager that works in parallel with the OS one, as well as a source code builder. With the number of dependencies, variation between platforms, etc., it can run into cases where it doesn't work so well.
On Fri, Oct 1, 2021 at 11:58 AM Glen Langston <glen.i.langs...@gmail.com> wrote: > > Hi Jeff, > > Thanks again for everyone’s continued efforts. > > We did get 3.8 working for several dongles, particularly the Airspy, air > spy > mini, rtlsdr and limesdrs. So that is great. > > Unfortunately the SDRPlay folks did not have time to get the SDRplay > included in the 3.8 revision we got running and I’ve been struggling with > that. > > I’d been able to use apt-get and various build steps working before. > What I find difficult is that each revision has a new preferred build > method. > I’d not needed PyBombs before now. > > I’m trying to follow the PyBombs instructions but it is > failing at the UHD step, which I don’t want anyway. So at the moment > I’m googling how to not install UHD on a raspberry pi, so that I can go > to the next step. > > A fairly simple question. Is PyBombs required for 3.9 and 3.10 > or could I go back to git clone and the build steps? > > Thanks > > Glen > > > , except that we could not get > > On Oct 1, 2021, at 11:35 AM, Jeff Long <willco...@gmail.com> wrote: > > > > SDRPlays work well with 3.8, 3.9 and 3.10 using multiple methods > mentioned by various people here. The proprietary drivers can make things a > little bit of a challenge. Sure, documentation can always use improvement, > and there's a big effort to work on that, all by volunteers. More > volunteers who use GR in different ways could always help. > > > > BTW, I'm sure you could find a more productive way to work on this than > responding to our release announcement with a complaint. I did offer to > help you figure some stuff out months ago and you never took us up on it. > > > > On Fri, Oct 1, 2021 at 10:51 AM Glen Langston <glen.i.langs...@gmail.com> > wrote: > > Hi Marcus and Franco and everyone, > > > > Thanks again for your help. > > > > I have to say, the online documentation is such a mess. I continue > > to wander into documentation that is obsolete but appears to be > current. I thought > > I’d found the perfect way, using pybombs, which suggested > > the latest version, 3.9, would be installed. > > > > But sadly, now I’m have way backwards to installing 3.7 gnuradio, but am > afraid to stop the > > build for fear of leaving a big mess behind. So I’ll try again after > this finishes. > > > > Concerning 3.9, there is, in my opinion, no excuse for killing SWIG for > the benefit of the future > > use of pybind. These should have both been enabled in gnuradio for a > transition period. > > Us who are actually trying to use gnuradio, not develop in it, do not > have the time or inclination > > to play around with confusing instructions that are only half correct. > > > > I’ve purchased too many SDRPlays, which work fine in 3.7 and are not > supported > > in 3.8, which we’ve finally struggled to get working. I continually > discover that bar is > > too high for _other_ experts to support the confusing gnuradio whims of > the re-organizers. > > > > Because gnuradio is a collaboration, changes that break the OLD should > strongly be avoided. > > Please strive to make changes that improve the code along new branches > so that are compatible > > with the old code. > > > > Thanks! > > > > Sorry for the continued rant, but we’ve been struggling to upgrade to > the latest branch > > for over a year now… By the time we get to 3.9 we expect that 3.10 > will be out. > > > > From what I heard from GRcon 21, many will leave gnuradio when > everything is broken in 4.0. > > > > Cheers > > > > Glen > > > > > On Oct 1, 2021, at 9:58 AM, Marcus D. Leech <patchvonbr...@gmail.com> > wrote: > > > > > > On 2021-10-01 7:34 a.m., Franco VENTURI wrote: > > >> If you are running GNU Radio >= 3.9, there's also the native SDRplay > module I wrote a big ago (https://github.com/fventuri/gr-sdrplay3) - you > can find the announcement to this mailing list here: > https://lists.gnu.org/archive/html/discuss-gnuradio/2020-08/msg00001.html > > >> > > >> Unfortunately it won't build on GNU Radio 3.8 because of SWIG. > > >> > > >> Since it interfaces to the native SDRplay API (version 3.X), it > doesn't require SoapySDR or gr-osmocom; I haven't done any comparison with > the other approaches of interfacing with the SDRplay RSP devices (SoapySDR > and gr-osmocom), but if someone does, I would be really interested in > hearing their results. > > >> > > >> Franco > > >> > > >> > > > My personal preference when writing applications is to make them > hardware-agnostic whenever possible, which is why I and am sure lots of > others > > > prefer the gr-osmosdr or gr-soapysdr approach of abstracting the > hardware interface. This is particularly important when the flow-graphs > you've > > > developed are going to be used by non-GR people, or even people who > have no particular expertise in modifying software. > > > > > > > > > > > > > > >
