Cmake is not my cup of tea

Software Ports
#1

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?

#2

Are you trying to build x265 with haikuporter?

#3

Yes exactly (forgot to mention, sorry)

#4

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?

#5

The block BUILD_PREREQUIRES has git commented out (statement 54)

How to check for this?

haikuporter fails because git is not found.

#6

What happens, if you remove the hashmark?

Haikuporter shows a list about the packages which is activated in the chroot every time you try to build a recipe.

So for some reason x265 now requires git. Either patch it out or add git to the build-time-dependency list (remove the hashmark).

It seems you dont understand how haikuporter works. Please spend more time with the HaikuPorter documentation: Home · haikuports/haikuports Wiki · GitHub

#7

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 :slight_smile:

#8

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.

1 Like
#9

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.

2 Likes
#10

That would be rather difficult as it seems there are more than 100 packages already using $cmakeDirArgs.

Can we perhaps introduce a new variable $cmakeDirArgsRelative?

#11

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?

#12

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/

#13

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.

#14

Indeed a system administrator has to update the haikuporter version on the builders. I can do that later today, I think.

1 Like
#15

HaikuPorter now updated on the builders.

I left a comment on the cmakeDirArgs change commit, though, did you see that?

1 Like