When transition period ends? about hunter

[bkotzz]

Hey folks, thanks for the interest. @rbsheth and I will be taking over the hunter project to keep it alive now that ruslo is stepping down.

It will be a bit rocky at first, but feel free to start sending pull requests in the usual fashion, and we will work through the kinks. There are relevant repos that haven’t been forked yet into the cpp-pm org, so some of the workflows might be adjusted slightly for now.

In general, we would like to work towards a team of maintainers rather than any one individual, so that the ownership burden can be shared. If you have contributed a fair amount to hunter in the past and are interested in this, please reach out to us.

In the short term, we will try to keep the flow of new/updated packages unimpeded, and have some ideas on how to smooth out the new package process that we’d like to explore.

Thank you!

[interj]

CMake (with dependencies)

If your project uses external packages (i.e. has command find_package(Foo)) you need to patch it first so these packages can be found in the Hunter root directory instead of the standard one:

This requirement doesn't seem to be true anymore (it probably never was actually). find_package uses hints to search for packages and you can inject hunter packages into vanilla cmake projects with dependencies. I can't say if it's true for every project, but find_package doesn't mean forking is necessary.
Take a look at example below - new version of spdlog was needed, stale version is present in hunter-packages. So instead of forking we injected fmt dependency in spdlog-injected/hunter.cmake using CMake builtin variables.

hunter_add_version(
    PACKAGE_NAME
    spdlog-injected
    VERSION
    1.3.94f35f
    URL
    ...
    SHA1
    ...
)

hunter_add_package(fmt)
find_package(fmt CONFIG REQUIRED)

hunter_cmake_args(
    spdlog-injected
    CMAKE_ARGS
        SPDLOG_FMT_EXTERNAL=ON
        "CMAKE_PREFIX_PATH=${FMT_ROOT}"
        "fmt_DIR=${FMT_ROOT}/lib/cmake/fmt"
)

[rbsheth]

Hi all, like @bkotzz said we have taken ownership of the hunter project and hope to make some enhancements to the contribution and CI process in the near term.

Right now, if you have a package addition or update, please feel free to send over a PR. If a new package needs a fork in https://github.com/cpp-pm, open an issue and tag us on it so that we can create a fork for you.

Please bear with us as we work through the kinks and make enhancements! 🙏

[tstack]

I'm hoping one of the new processes is removing the requirement to fork projects to add hunter-specific changes (i.e. everything under https://github.com/hunter-packages). The approach is completely unrealistic and just leaves around a lot of stale forks. I really don't see how hunter's approach to autoconf packages cannot be applied to cmake packages as well.

[caseymcc]

@tstack there was no requirement for that. The only reason some packages were handled that way was because they needed modifications to work with hunter that the upstream project would not take. If the project used "modern" cmake practices then hunter went directly to the main repo (or if the upstream accepted the needed modifications).

[bkotzz]

That is a fairly elegant way of updating spdlog without forking. We could probably even abstract some of that away, so that you just provide a list of dependencies to “inject”, and the rest is done for you. You’d still need to set some cmake args, but that’s not out of the ordinary.

In general, if we do feel like the forking model isn’t working for the common case, we can think about what it is that is being modified in those forks. Typically, the only changes being made are to add/modify a single cmake list, and to add the cmake config template. This is generally either because the project didn’t use cmake, or it did but in an incompatible way, like overriding parts of the toolchain or providing a build step but no install step. Thankfully, for the spdlog example above, this wasn’t the problem, but it often is.

In these cases, we could move towards a model where we consume the code from the upstream project’s release, but provide a hunterized cmake list directly in this repo that is used to build/install the upstream code.

This would remove the need for forking, and you would just put up a single PR against this repo to add a new version of a package, and possibly make any cmake changes necessary to build the new version’s source.

The only caveat is we’d still want to support multiple versions of a package, and sometimes there are enough changes between versions that the cmake list would be incompatible (a new dependency is added, the folder structure changed, etc). In that case maybe we’d either want a copy of the cmake list in this repo for each version of the package that is supported by hunter, or write the cmake list in such a way that we can reuse it across versions by passing in variables to control behaviour (ie. add dependency if version > X).

There are probably packages where this solution just wouldn’t work, but for a lot of them I think it would. Likely there is no one-size-fits-all solution, but having the ability to do all of these options would let the person adding/updating a package use the simplest one for their use case.

[caseymcc]

"If your project uses external packages", otherwise it is not a requirement. If you want the package to be able to use hunter packages it has to be modified to use hunter packages and if the upstream doesn't want those changes as they are "intrusive" then you have to have a fork. No one working on hunter wants to fork things, its generally not up to the person building the package but the original maintainer and they are generally like "why would I take changes for hunter, then I would have to take changes for all the c++ package managers", so hunter works around that issue when it arises. As for stale forks they are only "stale" cause someone has not been overly kind and gone out of their way to update the package for you.

[cyberium]

Would be nice to have a situation update to clarify what's happening.

As i understand @ruslo support ended and now we have officially this repo to support any new developments. Is that correct? How this will go now? Is it still safe to to use this for new project?

[xsacha]

Can I make pull requests?
Want to update OpenBLAS version to 0.37

[NukeBird]

Yes, devs please give us more information about what is happening

[NeroBurner]

In the short term, we will try to keep the flow of new/updated packages unimpeded, and have some ideas on how to smooth out the new package process that we’d like to explore.

could you elaborate on the possible new processes. I'm very interested in your ideas

[tstack]

@tstack there was no requirement for that.

The very first line of the hunter docs covering "Creating a new package with dependencies" say otherwise:

CMake (with dependencies)

If your project uses external packages (i.e. has command find_package(Foo)) you need to patch it first so these packages can be found in the Hunter root directory instead of the standard one:

And, there is a whole section in the FAQ titled "Why do we need forks?". So, yes, there is a requirement in the current model. And, looking at the pile of stale forks under hunter-packages, I would say that the current model is not working and needs to be revisited.

[xsacha]

OpenBLAS is a perfect example of an upstream CMake project (without dependencies) that you can just point to the upstream github URL and be done. See #2

[NeroBurner]

when can we expect this dependency-injecting. I'd like to use it for the OpenAL package, as the latest release openal-soft 1.19 has an SDL2 playback backend and I'd like to bring that into Hunter

[chfast]

Are you going to setup CI for this fork?

[bkotzz]

@NeroBurner the spdlog example above could be used today. That technique doesn’t require any new functionality.

@chfast yes, although in the current state of hunter, CI on the actual hunter repo only builds the docs, and we haven’t had a PR that touches docs yet, so it’s been low priority

[chfast]

@bkotzz I mean the one at https://github.com/ingenue/hunter. Can we use the same on for package additions/upgrades here?

[bkotzz]

@chfast we can use that one for now. As soon as that one needs to be changed (new package, or blacklisting a platform for an existing package) then we will need to fork it to cpp-pm

[bkotzz]

In the short term, we will try to keep the flow of new/updated packages unimpeded, and have some ideas on how to smooth out the new package process that we’d like to explore.

could you elaborate on the possible new processes. I'm very interested in your ideas

@NeroBurner #9

[rbsheth]

Closing this since it has been over a year since we took over and things are slowly improving. 😄