PengZheng edited a comment on pull request #401: URL: https://github.com/apache/celix/pull/401#issuecomment-1074808117
> It is also possible to update the GitHub Actions to use conan instead of directly working on cmake? > > Correct me if I am wrong, but I think if we use Conant on CI level, both the conanfile.py and the cmake configuration is tested. > > Or maybe we could add an extra build which build the now embedded test_package (and as result build celix and its deps) The existing actions test against distribution's native package manager. I think we should keep them running. Conan-driven test can be added like described by: http://codingadventures.org/2021/10/23/github-actions-and-conan/ Of course we need to add an extra `conan build` to turn Conan options into CMake cache variables. This we only have to properly setup options in the `conan install` step. For user's convenience, we may setup a Conan server, and create nightly packages, and uploaded all artifacts (including dependencies) for all mainstream platforms to the server. When a stable release ready, we can also upload it there. For nightly build, I think the following should be enough: ``` conan create . celix/2.2.3@zhengpeng/testing -tf examples/conan_test_package/ -o celix:celix_cxx=True -o celix:build_all=True conan upload "*" --all -r our_server ``` Our build-all package satisfies an immediate testing/prototyping purpose. Usually, our end users need to do some customization for Celix and its dependencies (OpenSSL/Curl). Conan support downstream customization, with the help of `-b missing`, our user can easily get what he/she wants. Ideally, we should release our package to the official conan-center. However, they promote build-system-neutral packages, while Celix is CMake-only: https://github.com/conan-io/conan-center-index/blob/master/docs/error_knowledge_base.md > [#KB-H016](): "CMAKE-MODULES-CONFIG-FILES" > The binary package cannot contain module or config CMake files ("Find*.cmake", "*Config.cmake", "*-config.cmake"). The package shouldn't contain specific build-system files to inform to the consumers how to link with it. In order to make sure that the package will be consumed with any build-system, conan-center repository encourages to declare a [def package_info(self)](https://docs.conan.io/en/latest/reference/conanfile/methods.html#package-info) method with all the needed information about the package. > The consumers of the package will be able to consume the packages using a specific [generators](https://docs.conan.io/en/latest/using_packages/conanfile_txt.html#generators) for the build system they use. Therefore, our package will trigger conan-center-hook errors. To solve this difficulty, we need to discuss it with conan developers. I plan to do it once I have Celix Conan package deployed in my day job and establish a (probably immature) CBD work flow. Before Conan-driven tests in place, I will watch for all changes to the master branch, and keep CMake/Conan consistent with the project structure. For example, there are several big PR pending, when merged, I will make necessary adjustments immediately. No need to worry other developers unintentionally breaking Conan support. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@celix.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
