x265 build system is based on cmake.
A particular script named Version.cmake should scan and find information about version of the lbrary and include those into the build, and in a statement it seeks for git:
find_package(Git QUIET)
Now, this never catches the git binary (I double checked: git is there, version 2.37.3 and when I remove that “QUIET” a string tells me git was not found) and the result is the version information is lost. How can I see how this script fails?
Further, into /boot/system/data/cmake/Modules I see a FindGit.cmake which gives:
cmake -P FindGit.cmake
-- Found Git: /bin/git (found version "2.37.3")
so, if I manage to replace that find_package command with this, it will surely find git.
How will I?
Does your recipe declares git as build-time dependency?
Is git actually attached to the chroot?
What happens if you invokes “git --version” in the first line of the BUILD() section?
Don’t know what you try to build, but even with cmake builds pkg-config is checked, so maybe add “cmd:pkg_config$secondaryArchSuffix” to BUILD_PREREQUIRES ?
EDIT add -L to cmake during build shows available options, and check the logs
Talking about cmake… I’m repeatedly getting into trouble with the way how haikuporter sets $cmakeDirArgs.
In particular: CMAKE_INSTALL_DATADIR, CMAKE_INSTALL_LIBDIR, CMAKE_INSTALL_MANDIR etc are configured as absolute paths while many projects rely on these being relative paths.
Is there any particular reason for this (apparently not so common) behavior?
some examples:
manpage install in libpcap, CMAKE_INSTALL_MANDIR is concatenated with CMAKE_INSTALL_PREFIX
rpath in audacity and tenacity uses CMAKE_INSTALL_LIBDIR as part of a relative path
wireshark: CMAKE_INSTALL_DATADIR is concatenated with CMAKE_INSTALL_PREFIX
I was reluctant to raise it as an issue in haikuporter github repo as I’m not sure if this is a bug or a design decision.
Probably I just copied most of the logic from runConfigure / $configureDirArgs and didn’t think too much about it. Please do work on fixing this, though be sure to test with any recipe that uses them already.
I meant “any” as in “at least one”, not “all.” These variables are really supposed to be processed by the GNUInstallDirs module, which I think handles both relative and fixed paths, so it may only be applications which don’t use GNUInstallDirs that we need to think about here?
How do you handle haikuporter updates on the builders? My PR for relative CMake dirs have been merged in haikuporter repo, so can I submit recipes that rely on this change? Or should I wait for a new haikuporter package release/
I think the builder needs to be manually updated and does not use the haikuporter package. It’s still a good idea to tag a new version of haikuporter from time to time, however, since not everyone runs it from the git repo.