Can we use our versions of those packages?

@SuperSandro2000 maybe, but it's not straightforward. It expects those tarballs to exist in a certain location, and tries to fetch them if they don't. I was able to patch that out, but it fails to build, because our version of mpack doesn't copy the header files.

My attempt is here: https://gist.github.com/deejayem/51e843e46dbcb92982522074c0b5f0e5

So we can either go with the version on this PR, or we can look at updating mpack to copy the header files, if you think that approach is better.

I'm not sure it would work though, as it also wants access to the C code for mpack and libb64.

mpack in nixpkgs isn't the same mpack being used here (the one in nixpkgs isn't anything to do with msgpack). I did get this working with libb64 and rapidjson from nixpkgs, and mpack from the tarball. So that's another option. Since it's by the same author as msgpack-tools, this mpack library might not be used by anything else, so probably isn't worth adding to nixpkgs. This version works: https://gist.github.com/deejayem/7847d7f5e741ca42ac21a5d46f6dc05c

@SuperSandro2000 what do you think? Should we stick with the approach currently used, which matches more closely what the upstream build does, or should I raise a PR to use libb64 and rapidjson from nixpkgs, as in the gist?

You can do all of that in this PR, we don't need to open multiple ones.

As NixOS is a distribution, we should use the distribution packages everywhere possible. I say if we go with the packages that already exist and use them, we are good. We probably don't need to add the library only used by this project.

This PR was opened by @petrzjunior so I don't think I can push to his branch. If he wants to commit the changes from my gist (and add me as a coauthor on the commit), then that would work. Otherwise I think I'd need to raise a new one.

Thank you for the comments. I'll have a look at it in a few days.

With the latest nixpkgs, there's a new error:

       > CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
       >   Compatibility with CMake < 3.5 has been removed from CMake.
       >
       >   Update the VERSION argument <min> value.  Or, use the <min>...<max> syntax
       >   to tell CMake that the project requires at least <min> but has been updated
       >   to work with policies introduced by <max> or earlier.
       >
       >   Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway.

Adding cmakeFlags = [ "-DCMAKE_POLICY_VERSION_MINIMUM=3.5" ]; fixes it, so you might want to do that as well. I think this overrides cmake_minimum_required(VERSION 2.6) in CMakeLists.txt

Yeah, can we have this in a different commit?

It'd be nice if we could get this into 25.11, so I've raised a new PR myself: #454597

@petrzjunior I hope you don't mind!

@JohnRTitor or @SuperSandro2000 would you mind reviewing that one please?

fetchFromGitHub can be used.

I've explained on the new PR why I don't think that's possible/optimal.