Hi Martin,
Regarding the API version "guarantee", I am wondering if there is any way
to distinguish between versions.  Presently, it seems that branches 3.12
and master both have UHD_VERSION set to 3120099.   I had previously been
using UHD_VERSION to select (via #if) code appropriate to a given UHD
version.  However, my function call to "get_device3()" compiles
successfully on master, but not on 3.12 (because this function is not part
of the 3.12 API). So, I keep having to change my source code whenever
compiling for one or the other.  Is there a way for me to avoid this?

Rob


On Mon, Jul 9, 2018 at 1:48 PM Martin Braun via USRP-users <
usrp-us...@lists.ettus.com> wrote:

> Hi all,
>
> we have recently been working more on the RFNoC side of things, and
> there's some updates I want to bring to you.
>
> The first step we did to a more stable version of RFNoC is merging all
> of the work on rfnoc-devel back into master. This will make it a lot
> easier to keep features in sync between RFNoC and regular/vanilla UHD.
> Going forward, we will no longer push updates to the rfnoc-devel
> branches, and at some point we will delete those branches in favour of
> master (for now, we'll leave them up so people following the existing
> instructions won't get an error, but they will be frozen as of now).
>
> For those of you who aren't actively developing on RFNoC, there is no
> difference (with the exception of E310 users, but I'll send out another
> email on that in a bit).
> For people playing with RFNoC, keep the following things in mind:
>
> - Anytime you read something referencing the rfnoc-devel branch, simply
> change that to master branch.
> - The RFNoC APIs are still disabled by default, and require using the
> -DENABLE_RFNOC=ON CMake switch to use them
> - If you have patches on top of rfnoc-devel, you may want to rebase them
> on top of master. They should cleanly apply, as of now, the diff between
> the two branches is minimal.
>
> Why do we require the `-DENABLE_RFNOC=ON`? The reason is, the APIs are
> not covered by our guarantee that we won't change them (in case you were
> unaware, we have a strong guarantee that we won't change APIs unless we
> also change the API version number, i.e., all 3.11.* releases have the
> same API). Think of setting that switch as a waiver that says "I have
> understood that I am using APIs that do not have a strong guarantee of
> being unchanged".
>
> On the FPGA branch, there is no such CMake switch, and the same branch
> will server RFNoC and non-RFNoC users alike.
>
> Thanks all!
>
> Martin
>
> _______________________________________________
> USRP-users mailing list
> usrp-us...@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to