-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RSDK-7861 Conan dependencies #283
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a great start, various questions and suggestions.
@lia-viam - Is this ready for another round of review? |
@acmorrow still needs work! last commits were just what I managed to fit in before vacation |
@acmorrow just re-requested a review, this is now in a state I'm more proud of. Before merging I would like to think about doing some of the following in CI
The possible pain point here is that we are already building from source, but then During development on this I kept wishing for RSDK-4735 so it might be nice to get that in soon, and would make it a bit less onerous to do the double build if that's the route we go. We also could just make it so conan stuff is a separate CI job which only gets built on releases. |
@@ -148,6 +148,121 @@ an installation tree under `build/install`. | |||
|
|||
If the build did not succeed, please see the next section. | |||
|
|||
## Building with `conan` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't know what conan is. I think it would be nice to add a docs link closer to the beginning (maybe hyperlinked to its first mention) so users can familiarize themselves with the 3rd party pkg
(I initially read canon
like James' docker thing haha)
BUILDING.md
Outdated
while using `conan` to get dependencies instead of your system package | ||
manager. Note that Option 1 implies a superset of Option 2. | ||
|
||
### Creating and consuming the SDK `conan` package. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is option 1 right? Can we do Option 1: Creating and consuming the SDK
conan package.
BUILDING.md
Outdated
or look at the [`test_package/conanfile.py`](test_package/conanfile.py) | ||
which is the test package recipe. | ||
|
||
### Using `conan` to manage the SDK dependencies |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same thing for Option 2:
Note that this can be done with the same `CMakeLists.txt` from the | ||
[example project](src/viam/examples/project/cmake/CMakeLists.txt): it is | ||
agnostic of the use of `conan` to package the SDK as opposed to the SDK | ||
having been built and installed manually. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this due to the flexibility of using find_package
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pretty much yeah! In the snippet above when you do cmake --preset=conan-release
that's where conan makes it so that find_package
will know about the packages it has installed, but all of that takes place on the command line rather than intrusively in the CMakeLists.txt itself
@hexbabe thanks for the doc comments, I've pushed some changes! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks really good. All small things / questions and a few small suggestions. My only real concern is re the hardcoded version numbers.
conanfile.py
Outdated
|
||
class ViamCppSdkRecipe(ConanFile): | ||
name = "viam-cpp-sdk" | ||
version = "0.0.10" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There will need to be something in the release process to advance this number, or it will surely drift. Can we derive it somehow?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah this was bugging me as well and I stumbled on this in the old 1.x conan docs:
https://docs.conan.io/en/1.4/howtos/capture_version.html
Going to ask online if this is still considered acceptable
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If there isn't a good way, we can always doc it in the release process.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Update: turns out set_version
does what I needed
@@ -0,0 +1,6 @@ | |||
[requires] | |||
viam-cpp-sdk/0.0.10 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ditto re version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok so this part I think we might not be able to derive the version programatically. In keeping with the spirit that stuff in the examples/project
directory should be usable as starter code, a conanfile.txt
is the easiest way to get started with a conan
project that depends on the SDK.
A conanfile.py
could in theory get the version like the root conanfile.py
as sketched above, but then this would be grabbing a version from ../../../../CMakeLists.txt
which would probably merit an all-caps warning comment to delete that in your own project and write in an explicit version.
We could specify a version range like viam-cpp-sdk/[>=0.0.12]
(or whichever release this lands in) but I don't love that.
I think the last option is that if the SDK release instructions say "manually bump the version in the CML.txt and also the example project conanfile.txt" which might not be so terrible
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I hadn't really caught that this was in the example. I just saw a hardcoded version and the usual reflexes kicked in. I don't know: I sort of find the viam-cpp-sdk/[>=0.0.12]
sort of intuitively appealing? Can you elaborate on why you don't love it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it might be fine actually, looking at https://docs.conan.io/2/tutorial/versioning/version_ranges.html it seems like it will prefer to use the newer one if available, just trying to imagine a situation where the user is accidentally getting an old version because they hadn't yet built a new one
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
switched to using a version range!
src/viam/sdk/CMakeLists.txt
Outdated
@@ -237,6 +237,8 @@ target_link_libraries(viamsdk | |||
PRIVATE absl::strings | |||
PRIVATE viam_rust_utils | |||
PRIVATE Threads::Threads | |||
PRIVATE $<$<PLATFORM_ID:Linux>:dl> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not that it matters, but I'd bet a shiny nickel these are needed on, say, BSD. Is there a more general platform tag than Linux?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted to ask you about that, it comes up in the conanfile too. It seems to be idiomatic to do the following:
https://github.com/conan-io/conan-center-index/blob/master/recipes/grpc/all/conanfile.py#L302
And I figured we may as well do the same even if we don't claim in the README to support BSD. But yes I can do a Linux || BSD
clause here and in the conanfile
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the sdk/CML.txt we do an if (APPLE)
to link -framework Security
so I may just spell this as an if (NOT APPLE)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, the reason for that -framework Security
is interesting, btw: https://github.com/viamrobotics/viam-cpp-sdk/pull/146/files#r1334516668.
Essentially, it is viam_rust_utils that has a dependency on the Security
framework on macOS. However, since we don't obtain viam_rust_utils via a find_package like thing, there is no way for it to express its transitive dependencies.
I'm not particularly happy about needing to do that, but I don't have a better answer.
Regarding your suggestion to make this just be "not apple", I think that makes sense. Maybe do "not apple and not windows?"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ahh that explains a lot, I think that's why I ended up needing to add librt
and libdl
too, I was getting linker errors from viam_rust_utils
on the static build without them.
As for not windows, I don't think there is currently any mention of windows in our build files, are we hoping to be able to offer it down the road?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Dependency management with conan--provides a recipe for packaging the SDK with conan and some examples/docs to support
Currently tested on mac as well as bullseye docker container, featuring configuration options listed in the
options
of theconanfile.py
TBD: