Closed willjschmitt closed 3 months ago
It makes absolutely sense to have install information in the CMake files. I integrated your proposal into the default branch and merged your #35. Let me know if your issue is resolved now.
Perfect! Thanks so much. This works exactly as desired referencing HEAD, and confirmed end-to-end I'm set up with a successful bazel build (for Windows and Linux) and loaded the plugin successfully into Oxygen (Windows only at this point)
Thanks for the feedback, I added a small installation change where I put include files in /usr/local/include/odk/*
now. I hope this causes no problems for your workflow, but it makes include files better grouped.
That shouldn't impact our workflow, since we can strip the odk/
suffix off the install path in our build, but it does sound like you're hinting at the includes including odk/
as a prefix:
include "odk/odkfw_software_channel_plugin.h"
which is at odds with the current include statements throughout the repo.
Otherwise, I think folks will need to explicitly add the namespaced include path, which isn't a huge deal and doesn't impact our build (since odk/
will be stripped anyways), but just adds more compiler flag configuration for projects compiling against it and sortof defeats installing to the system include paths
We use a non-cmake build system (Bazel) to manage a monorepo, which means we need a clean wall between the output artifacts of the ODK and our plugin implementations, which will be built using Bazel and our own compiler toolchain configurations. Bazel supports builds depending on cmake-built libraries via
rules_foreign_cc
, specifically thecmake
rule, but the rule depend on artifacts to be written to the install directory, rather than reaching into the intermediate build-directory. I could propose to them to try to support reaching into build-directories, but I figure that will be a bigger reach than additively supporting install commands in this project. I think it should be pretty compatible with the existing cmakelists files, and thepugixml
third-party lib offers an example of installing its headers and libraries to the install directory in a generalized and unintrusive way: https://github.com/DEWETRON/OXYGEN-SDK/blob/master/3rdparty/pugixml-1.9/CMakeLists.txt#L67-L72For now, we're monkey patching in the
install
commands, which I'm happy to contribute as a PR if it's compatible with how you're thinking about your cmake builds. Here's the patch (with one additional line needing adding where there was a missing header file in theHEADERS
variable for the api library, which I'll submit a PR for separately anyways):