Closed mathisloge closed 4 years ago
Hi Mathis, Adding support for various package managers (including vcpkg) is one of my future goals. However, I didn't have a chance to use them in my line of work yet and to learn / practice their configurations. It would be great if you help.
As for your question, the COMMS_INSTALL_DIR
variable is there to provide a path to the externally built and installed comms_champion project. That's where the find_package will look for LibCommsConfig.cmake
file. Sorry, but I'm not aware of the way how vcpkg is building things (or where it installs the built package) and managing their dependencies. Any suggestions on how to improve the existing logic are welcome.
Hi Alex, I'll work a bit on the integration and check if we have to improve the existing logic. I will keep you updated.
https://github.com/microsoft/vcpkg/pull/14195 will integrate comms and commsdsl.
comms without the plugins/gui support
Hi Alex, so currently the build fails on the vcpkg CI Compiler Info: config-x64-linux-dbg-out.log
Build error: install-x64-linux-dbg-out.log
It will fail on linux but not on windows.
Do you have some knowledge of that?
Hi Mathis, It looks like it's a problem with stand-alone boost. Someone has reported it to me at cc.demo1.commsdsl project. However it was resolved when boost provided by ubuntu was used. Google also gave me this link. It looks like libreoffice encountered the same problem and had to patch their boost. I think the proper solution would be patching boost in vcpkg, but I can try to pass "-Wno-undef" to command line arguments when compiled with gcc as a workaround. I think I'll put it in "develop" branch soon and will release it in a week or two.
Hi Alex, thanks for the info. I can make a patch directly in the port definition of commsdsl in vcpkg without modifying the underlying code base.
Hi Mathis, Please take a look at current fix to "develop" branch here. You can drop the MSVC line and leave only the GNU one. Also note that I'm currently working on fixes to both "comms_champion" and "commsdsl" projects to allow builds with "/W4" warning level (currently it's building with default "/W3"). I hope to heave a release ready in about one week time. Maybe it's worth to wait rather than prepare a patch.
I suppose if you prepare patch to the commsdsl project, it's going to be applicable only for v3.5.2 release right? If I do v3.5.3 the patch is not going to be applied automatically, is it not? How is all the versions management is performed in vcpkg?
Hi Alex,
Each project is organized in so called "ports". Each port has currently a fixed project version. (more than one version is currently under development, but not released. So currently we only have one version of each library)
At the current vcpkg development stage, one will have to provide a update to the port file to update the project.
Each port can have multiple patches as git diffs. If one patch isn't needed in the next project version, the patch can simply be deleted.
So, if I understand you correctly the vcpkg has "always live at head" philosophy. I simplifies many things, but what's the expected workflow when new version of some package compiles fine (as the result merged to ports), but contains some bug and the clients that use that package want a previous version? What happens when newest version deprecates and removes some functionality? What happens to the dependent packages that still use old API?
Not always on head. Always on a specified version of that library. At each upgrade you will check if the applied patches are still needed. If not, you will remove them.
If you want to upgrade a library and other dependent libraries are breaking with the upgrade. You have to fix the breaking libraries in your upgrade pull request, too.
I see. For me personally a limitation of having a single version of the package where an upgrade to a widely used one (boost for example) can break multiple independent packages (when some deprecated API gets removed for example) brings the vcpkg to a "hobby" level and I don't see myself using it in the commercial production environment. I also encountered this issue which was an educating read, but I digress.
I just thought that disable treating warnings as errors may also resolve the problem without any patches, just pass -DCOMMSDSL_NO_WARN_AS_ERR=ON to the cmake configuration of the commsdsl project.
yes, the single version is indeed a limitation currently. But the multiversioned ports are under development: https://github.com/strega-nil/vcpkg/blob/git-registries/docs/specifications/registries-2.md https://github.com/microsoft/vcpkg/pull/14153
So thats a step in the right direction for commercial use.
I also took a closer look at your pull request (at comms branch) and I introduced some extra fixes to the CMakeLists.txt files that could help to avoid the patches in the next version. I'll appreciate it if you could review and test my work (on "develop" branch for now) against your vcpkg local copy. I don't know when I'll be able to allocate the time and dive deeper into the vcpkg and test it myself.
awesome! looks good to me. I'll test it tomorrow on my local repo.
the comms champ and commsdsl is now merged into the vcpkg master branch.
install command for commschamp:
vcpkg install comms
install command for commsdsl:
vcpkg install commsdsl
if you want both libs - just run vcpkg install commsdsl
it will install all necessary dependencies.
That's awesome! Thanks Mathis for your contribution.
Hey,
I'm currently looking into adding commsdsl and commschampion to vcpkg. The work is currently here https://github.com/mathisloge/vcpkg/tree/commsdsl
I think it might be a cool addition to this library/tool. What do you think?
Currently i'm stuck configuring the commsdsl repo to use the libcomms built by vcpkg. Is there a way to directly use
find_package(LibComms CONFIG REQUIRED)
to use the external commschampion?This is a bit too hardcoded for vcpkg https://github.com/commschamp/commsdsl/blob/master/CMakeLists.txt#L32