search

pothosware / SoapySDRPlay2

Soapy SDR plugin for SDRPlay
MIT License
51 stars 11 forks source link

build error: libsdrplay not found #65

Closed fyngyrz closed 4 years ago

fyngyrz commented 4 years ago

build error: libsdrplay not found.

As provided, this will not build.

darksidelemm commented 4 years ago

It looks like this Soapy package is only going to work with v2 of the SDRPlay SPI, which means those of us with brand new RSPdx units will miss out for a while...

Looking at https://github.com/pothosware/SoapySDRPlay/blob/master/FindLibSDRplay.cmake, it's looking for mir_sdr_api.h, etc... whereas the new api is present as /usr/local/include/sdrplay_api.h

SDRplay commented 4 years ago

See here for the v3 version: https://github.com/SDRplay/SoapySDRPlay

It's still in development but you can raise issues there is you find any.

SDRplay

darksidelemm commented 4 years ago

I'm not sure closing the issue is the best idea - it's going to make it hard for anyone with the same issue to find this link.

Perhaps keep the issue open until the v3 changes have been merged into this repo, but change the issue title to "RSPdx / v3 API support" ?

SDRplay commented 4 years ago

I've updated the Readme to explain about the V3 version

nickoe commented 3 years ago

See here for the v3 version: https://github.com/SDRplay/SoapySDRPlay

It's still in development but you can raise issues there is you find any.

SDRplay

@SDRplay Hi. I am not sure understand this. Is that "development" repo supposed to be the new "SoapySDRPlay" in "pothosware"? Why is the git history not based on a common commit? (there are fewer commits in https://github.com/SDRplay/SoapySDRPlay on master than on the repo in pothosware. Whats the idea behind this?

SDRplay commented 3 years ago

https://github.com/pothosware/SoapySDRPlay is based on API 2.13

https://github.com/SDRplay/SoapySDRPlay is based on API 3.07

so there isn't a lot of code in common.

nickoe commented 3 years ago

@SDRplay API version of what exactly?

SDRplay commented 3 years ago

The RSP hardware API

guruofquality commented 3 years ago 
https://github.com/pothosware/SoapySDRPlay is based on API 2.13

https://github.com/SDRplay/SoapySDRPlay is based on API 3.07

In an effort to not confuse people, should support for the "API 2.13" be dropped and links updated? Is SDRplay/SoapySDRPlay the new official home? Or could we merge both trees into the same repo that builds one or the other, (or even both) based on the API installed?

guruofquality commented 3 years ago

@SDRplay what repo should I build if I am packaging this into a windows installer? Should I move to the 3.07 API?

SDRplay commented 3 years ago

API 2.13 is no longer being developed and it doesn't support the RSPdx or the RSPduo in master/slave or dual tuner mode.

So going forward I would recommend all installs to be based on API 3.07

Best regards,

Andy

guruofquality commented 3 years ago

@SDRplay any suggestion about how to transition away from this repo?

1) I could delete pothosware/SoapySDRPlay or rename it to SDRPlayOLD or SDRPlay2.0 2) Combine the repo into SDRplay/SoapySDRPlay so 2.0 API build would exist as a deprecated subdirectory in the new one, just in case someone wanted to build it 3) Or move SDRplay/SoapySDRPlay here and replace the contents of pothosware/SoapySDRPlay

At the end of the day I dont care where the repo lives but I need to make some consistency for users, build systems, various urls on the website. No sense in linking to a defuct project. Thoughts?

SDRplay commented 3 years ago

I think ultimately it makes sense for SoapySDRPlay to reside in pothosware. Setting up the API 3.07 version in a different repo seemed to make sense to avoid any issues with the pothosware flow.

I don't really have any preference as long as it is clear to people with what is where. @fventuri has done the lion share of the work, so I think he should comment on how to move this forward.

fventuri commented 3 years ago

I like the idea of having have two separate repos (one more or less identical to the current one under SDRplay and the other one with the legacy 2.X from pothosware renamed as @guruofquality suggested); this way we can keep the code bases (and issues reported by the users) separate as much we can.

Once this is in place, how would I fix bugs or make improvements to that driver? By forking under my own account ('fventuri') and submitting a pull request? (I am perfectly OK with this approach; just trying to figure out how things will work in the future).

Franco

guruofquality commented 3 years ago

Heres what I can do:

1) I will rename this repo to SoapySDRPlay2x 2) move SDRplay/SoapySDRPlay to me @guruofquality (and then I can move it here) 3) I will invite you to the dev group, you get repo access @fventuri

guruofquality commented 3 years ago

@fventuri invite sent

If everyone is happy with the plan, @SDRplay if you kickoff the repo move of SDRplay/SoapySDRPlay, I will kickoff the rename at the same time so its all at once

fventuri commented 3 years ago

Thanks @guruofquality - I just accepted the invite, and I am OK with the plan. It might be late for @SDRplay now, since he is in the UK.

Franco

guruofquality commented 3 years ago

@SDRplay bump

:-D

SDRplay commented 3 years ago

Sorry @guruofquality, we've just been discussing it internally. Everything is all good. Just let me know what you need me to do.

Best regards,

Andy

nickoe commented 3 years ago

@guruofquality @SDRplay I won't interfere, but just as an outsider, this is my comment.

I think you can just have both of the source trees in this very same repo and just have two branches.Technically they don't even need to have the same ancestor to be two different branches. But then decide on a "stable" branch name. api_ver_2x for example and just keep the api ver 3 development in master og make a breach for that as well and just do fast forward from master when tagging a release. All I am looking for is, what I should pull for whatever version of libsdrplay I have installed.

fventuri commented 3 years ago

Very good points @nickoe

I usually tend to think of branches as improvements or fixes to a well defined code base - in this case though I don't view version 3.X of the SDRplay API as an incremental improvement over version 2.Y (or viceversa), because they have a somewhat different way of selecting the RSPs (which is very noticeable in the case of the RSPduo model), sample rate, bandwidths, etc.

Another factor that in my opinion weights in favor of different repositories is having two completely different 'issues' queues, both for me as a developer (because I know in advance that the 'issues' on the SoapySDRPlay repo refer to API version 3.X), but also for a customer with a problem, because, when looking for a solution to a problem, they would not get a list of issues that possibly intermingles problems with version 2 of the SDRplay API and problems with version 3 of the SDRplay API.

Also it would possibly help with handling and reviewing any pull request, because we would know right away if it refers to version 2.X of SoapySDRPlay (which some people here might be more familiar with), as opposed to version 3.Y of SoapySDRPlay (which a different group of people might be more familiar with).

This all said, these are not strong opinions on my side, and I am definitely open to discuss them to find the best approach that suits everyone.

Franco

nickoe commented 3 years ago

@fventuri Thank you for your openness. My opinions are not strong either.

Just a note about github. If the current pothosware/SoapySDRPlay repo at is renamed to pothosware/SoapySDRPlay2 in github, the current (soon old) will redirect to that. And then the SDRplay/SoapySDRPlay can be moved to pothosware/SoapySDRPlay3 and it is way more visible for packagers and users alike.

guruofquality commented 3 years ago

Sounds good to me. When I get the transfer request in my inbox I will do both of those moves/renames and update the wiki URLs

SDRplay commented 3 years ago

Just want to make sure I understand - there will still be https://github.com/pothosware/SoapySDRPlay though right? This runs through every bit of documentation and videos that we've ever done. It still needs to exist - even if it just points to somewhere else.

guruofquality commented 3 years ago

Thats a good point, the rename would make githubs URL redirects of pothosware/SoapySDRPlay redirect to pothosware/SoapySDRPlay2. And I think at the end of the day we want pothosware/SoapySDRPlay to exist and to be the recent maintained repo that people look for (the v3 repo).

That said, I will be happy to cooperate with whatever the names should be and follow the instructions :-)

fventuri commented 3 years ago

So, if I understand correctly, the plan would consist of two phases:

Does that sound about right?

Franco

SDRplay commented 3 years ago

We don't want to make the API 3 version harder to find - it needs to be the one pointed to, so pothosware/SoapySDRPlay should go to pothosware/SoapySDRPlay3 - all agreed?

fventuri commented 3 years ago

Works for me @SDRplay , so unless there are objections this would be the plan:

If we are all in agreement, I'd say let's go ahead and do it.

Franco

nickoe commented 3 years ago
  • 'pothosware/SoapySDRPlay' moved to 'pothosware/SoapySDRPlay2'
  • 'SDRplay/SoapySDRPlay' moved to 'pothosware/SoapySDRPlay3'
  • 'pothosware/SoapySDRPlay' will be a redirect to 'pothosware/SoapySDRPlay3'

Just a small detail: I think you can only make github redirect if you move in the webinterface, so I you you need these operations; in this order.

  1. 'pothosware/SoapySDRPlay' move to 'pothosware/SoapySDRPlay2'
  2. 'SDRplay/SoapySDRPlay' move to 'pothosware/SoapySDRPlay'
  3. 'pothosware/SoapySDRPlay' move to 'pothosware/SoapySDRPlay3' to make it redirect to 3.
guruofquality commented 3 years ago

@nickoe thanks, thats what I was going to do, I dont think you can actually setup the redirects manually, you have to move projects to get the effect.

@SDRplay im ready when you are. We will end up with pothosware/SoapySDRPlay2 and pothosware/SoapySDRPlay3, where pothosware/SoapySDRPlay redirects to pothosware/SoapySDRPlay3 (following @nickoe instructions).

nickoe commented 3 years ago

@guruofquality @SDRplay Any update to this such that we can make the life easier for packagers?

guruofquality commented 3 years ago

The move and rename is complete, do let me know of any permissions or url issues. Thanks!

nickoe commented 3 years ago

@guruofquality Thank you very much. I think it makes it easier to navigate.