CMAKE_ARGS for the package will be calculated once before first dependency build. See the
HunterGate parameters of the dependency, including local customization, will be ignored and taken fully from a parent.
Should the flags be put in the hunter.cmake hunter_cmake_args or is there another way to handle it?
Yes, you can add them to
hunter_cmake_args upstream or in your own fork, or you can mention the
CMAKE_ARGS in documentation.
I tried put the flags in the HastyNoise/hunter.cmake file using hunter_cmake_args(Boost CMAKE_ARGS ...) hoping that it would be picked up there
@caseymcc It should not work, it's designed to be used for the current project only, not for dependency.
Is this correct or is there a way for HastyNoise to force the boost flags without the parent knowing?
That would be quite surprising if doing
hunter_add_package(Boost COMPONENTS system) will do static boost.system build, but doing
hunter_add_package(Boost COMPONENTS system) + hunter_add_package(HastyNoise) will switch it to shared boost.system build.
but the default config on clang seems to fail on an -fPic issue that I am not very familiar with
I need details, why it's failing? You forced SHARED library somewhere?
Example of adding
HUNTER_BUILD_SHARED_LIBS=ON to test:
Example of mentioning
PIC toolchain in documentation:
pkg-configexecutable with Hunter we can initialialize
PKG_CONFIG_EXECUTABLEaccordingly. So there will be no necessity to have it in the system.
Why can the autotools builds get away with using DEPENDS_ON_PACKAGES, but a fork is needed for a cmake-based project?
@tstack Forks are easier to maintain if the structure is complex. If you move internal stuff out of the package and put it into Hunter code that leads to maintaining hell with
if(*_VERSION VERSION_LESS ...). E.g. see Boost:
Or something fresh:
Just for your info you can get rid of hunter_add_package by this improvement in theory:
I've been trying to use packages that have been forked and they aren't being updated to the latest version
Where and how the package related patches are stored and the frequency of package updates seem to be independent issues. If hunter stored the package patches inside the repository, I don't see how this would translate to more frequent updates.
Where and how the package related patches are stored and the frequency of package updates seem to be independent issues.
Again, I'm talking about cases where the patch is solely about adding
hunter_add_package() calls. Requiring a fork in that case instead of just being able to express the dependency in the hunter.cmake file (or, ideally, mining it out of the package's CMakeLists.txt file) increases the maintenance burden to a great degree.
if it were rolled into cmake as a feature, it could be very powerful
@wheybags There is no need to have the whole Hunter in CMake. You only need
If you could implement next features:
HunterGatefunctionality as a standard module in CMake
SHA1for "get latest" request
find_package: https://github.com/forexample/cmake-find-package-include to get rid of
CMAKE_FIND_PACKAGE_PREFER_CONFIG=ONto get rid of
Then you can do:
# CMakeLists.txt cmake_minimum_required(VERSION 3.2) project(foo) find_package(Boost REQUIRED system filesystem iostreams) find_package(ZLIB REQUIRED)
cmake -H. -B_builds -DHUNTER_ENABLED=ON
to satistify dependencies automatically with Hunter.
cmake -H. -B_builds -DHUNTER_SHA1=32cfed254da901f6f184027d530d8da47e035b85
for reproducible build.
@needs If you push back changes to the server and make a release, you can use "Protected sources" feature:
Also, you can pack submodule on-the-fly:
I'm looking for xsd (codesynthesis) and xerces packages. Seems like they are not available on hunter
Ok I'm not the first one to look for xerces