treewide: move to libiio 1.0i API

[nunojsa]

While at it, increased cmake minimum version to 3.10 as in other projects.

@pcercuei, your review would be valuable in here. Note that I'm only moving from one API to another. Not code refactor is intended at all (only the cmake stuff to avoid an annoying warning)

@tfcollins this is only compile tested so it would be great if you or someone else could give this a test.

[pcercuei]

I'd hold that for now, I plan to rework how the attributes are accessed in Libiio v1.0 - which should be ready by the end of next week.
(I'm on vacation this week FYI)

[nunojsa]

I'd hold that for now, I plan to rework how the attributes are accessed in Libiio v1.0 - which should be ready by the end of next week.
(I'm on vacation this week FYI)

Alright, I'm also not sure what's the plan here (I see CI also needs updating when moving to 1.0).

The background for the PR is that meta-adi main branch follows the other projects main branch. Therefore, all projects (this one and the adrv9009-monitor) that depend on libiio are now failing to build. Anyways, I guess it might takes some time for the dust to settle, so I might just temporarily point the libiio recipe to the libiio-v0 branch.

[tfcollins]

@tagoylo can you check the hardware harness to make sure this runs without issue

[tagoylo]

Following errors were encountered when after running make

[100%] Linking C executable FMComms5SyncTest
/usr/bin/ld: CMakeFiles/FMComms5SyncTest.dir/fmcomms5_sync_test.c.o: in function 'check_phase_sma':
fmcomms5_sync_test.c:(.text+0x8d8): undefined reference to 'iio_create_channels_jmask'
collect2: error: ld returned 1 exit status
make[2]: *** [test/CMakeFiles/FMComms5SyncTest.dir/build.make:86: test/FMComms5SyncTest] Error 1
make[1]: *** [CMakeFiles/Makefile2:288: test/CMakeFiles/FMComms5SyncTest.dir/all] Error 2
make: *** [Makefile:163: all] Error 2
script returned exit code 2

Full log:
libad9361-make-error.txt

libiio branch used: main

[nunojsa]

Full log:
libad9361-make-error.txt

libiio branch used: main

It looks like i added some typo right before the pull... will update soon

[nunojsa]

@tagoylo, pushed out a new version. let me know if it compiles now...

[tfcollins]

This works fine in hardware CI now. Have @ccraluca take a look at the Azure updates needed

[pcercuei]

@tfcollins I think @ccraluca will be out for a few months at least, so somebody else should do it.

[tfcollins]

@tfcollins I think @ccraluca will be out for a few months at least, so somebody else should do it.

@SRaus who can look at the Azure pieces?

[AAndrisa]

I created a branch from 'staging/libiio1-support' called 'staging/libiio1-artifacts' and made changes so that the artifacts are now taken from the main branch of libiio but it seems that are still some build issues. Or should this change still use artifacts from libiio-v0 branch?

[SRaus]

I would go with fixing 'main' issues ASAP and keep using artifacts from 'main' instead of "libiio-v0".

[pcercuei]

@SRaus the API of Libiio in the main branch won't be stable until the v1.0 release is tagged.
So I'd advise against updating anything to the will-be-v1.0 API (unless it's for testing purpose - then yes please) as it's bound to be broken at some point.

[tfcollins]

@SRaus the API of Libiio in the main branch won't be stable until the v1.0 release is tagged. So I'd advise against updating anything to the will-be-v1.0 API (unless it's for testing purpose - then yes please) as it's bound to be broken at some point.

This would probably be a useful canary build to have though. I think we have the following options:

1. Support both with feature flags
2. Merge this with some CMake updates to help with versioning checks if possible. We really need a true CMake config in libiio and libad9361 that allows for the use of find_package anyway
3. Move to a stable/next_stable/main type branching strategy first

[SRaus]

the API of Libiio in the main branch won't be stable until the v1.0 release is tagged

In this case, from my point of view, this means that it shouldn't be in master yet.
But instead, the changes should be in a dev branch, manually build and test libad9361 (and all other components that use libiio) with artifacts from that specific dev branch. Finally, when everything was clear, to push to master/main all PR's from all dependent repos on the same time.

[SRaus]

This would probably be a useful canary build to have though. I think we have the following options:

1. Support both with feature flags
2. Merge this with some CMake updates to help with versioning checks if possible. We really need a true CMake config in libiio and libad9361 that allows for the use of find_package anyway
3. Move to a stable/next_stable/main type branching strategy first

In this case, I would go with #2 , definitely not touching next_stable (which we are trying to stabilize) or last_stable.

[pcercuei]

the API of Libiio in the main branch won't be stable until the v1.0 release is tagged

In this case, from my point of view, this means that it shouldn't be in master yet. But instead, the changes should be in a dev branch, manually build and test libad9361 (and all other components that use libiio) with artifacts from that specific dev branch. Finally, when everything was clear, to push to master/main all PR's from all dependent repos on the same time.

The "master" branch (now "main") has always been a development branch. If you want a stable experience, use the releases. And I did work on a separate "dev" branch for about two years before it was eventually merged back into "master". Did you test libad9361 vs. the dev branch then?

[SRaus]

the API of Libiio in the main branch won't be stable until the v1.0 release is tagged

In this case, from my point of view, this means that it shouldn't be in master yet. But instead, the changes should be in a dev branch, manually build and test libad9361 (and all other components that use libiio) with artifacts from that specific dev branch. Finally, when everything was clear, to push to master/main all PR's from all dependent repos on the same time.

The "master" branch (now "main") has always been a development branch. If you want a stable experience, use the releases. And I did work on a separate "dev" branch for about two years before it was eventually merged back into "master". Did you test libad9361 vs. the dev branch then?

Haven't tested libad9361 with dependencies from dev branch - I'm expecting that beside testing, libad repos are requiring some changes in order to work.

Regarding libiio releases - I agree that they are stable and we can rely on them.
But can we build/test latest libad9361 with artifacts from latest libiio release? (Probably yes right now, since latest release is pretty recent / and probably no one month ago, before creating v0.25, since previous release would have been too old - more than one year old).