a tag or a release about cppdap

[thesamesam]

This would be appreciated now that CMake as of 3.27 (optionally) depends on cppdap for its debugging functionality.

[ben-clayton]

Given that there's no official release process, what would the tag or release provide that a SHA does not?

[thesamesam]

GitHub tarballs aren't stable and have historically changed hashes after a while: https://github.com/orgs/community/discussions/45830 and https://github.blog/changelog/2023-01-30-git-archive-checksums-may-change/.

So, even just some arbitrary tag (even every tag if that's easier for automation) as an uploaded asset has some value for us in distros, if it's possible.

[ben-clayton]

I can add tags or branches but I'm still not entirely convinced by the argument here.

The encouraged workflow is to compile cppdap from source and statically link into your code. cppdap is tiny, building from source takes negligible time. I would encourage people to depend on cppdap via a git submodule, or any other form of dependency pinning.

cppdap is not SemVer'd. While we try to avoid breaking changes, they will happen - especially as this is a wrapper around an evolving RPC protocol. Given the lack of compatibility guarantees, I actively discourage the use of cppdap in a distro package.

Maybe I'm missing additional context here. Please feel free to convince me otherwise!

[thesamesam]

Yeah, I can understand it. The only reason I'm packaging it is purely for CMake's use (which allows using system versions of dependencies). Nothing else is using the system copy as it is. I can live with the status quo though.

Thanks for discussing it - I'll let the original reporter chime in as well, as I don't know what their motivations were.

[MehdiChinoune]

CMake now depends on CPPDAP for cmake code debugging.
We are trying to package CPPDAP and build CMake against it.

[ben-clayton]

I'd like to understand the problem a little more before making changes.

CMake now depends on CPPDAP for cmake code debugging. We are trying to package CPPDAP and build CMake against it.

Who is We?

CMake appears to be using a Git hash for the version of cppdap that it depends on. Is there any reason you can't use this?

If I add a tag or branch, how do you ensure that you stay in sync with the version that CMake is built and tested against? If they're not at the same version, there's a very good chance it won't build - or worse, it will, but will behave subtly different at runtime.

[MehdiChinoune]

Who is We?

MSYS2 packagers.

CMake appears to be using a Git hash for the version of cppdap that it depends on. Is there any reason you can't use this?

We prefer to package tags/releases.

If I add a tag or branch, how do you ensure that you stay in sync with the version that CMake is built and tested against? If they're not at the same version, there's a very good chance it won't build - or worse, it will, but will behave subtly different at runtime.

like any other package, We either report issues to CMake or to you, if something go wrong.

[ben-clayton]

I've created the tag dap-1.58.0-a. This is one change ahead of the CMake's current Git hash.

I'd recommend you coordinate with CMake to ensure you use the same revision.

[MehdiChinoune]

Thanks!