Help understanding buildInputs + cmake

Help
1

I have a derivation for a library that looks like this:

{
  lib,
  stdenv,
  cmake,
  fetchFromGitHub,
  zlib,
  libxml2,
}:
stdenv.mkDerivation (finalAttrs: {
  pname = "tmx";
  version = "1.10.0";
  src = fetchFromGitHub {
    owner = "baylej";
    repo = "tmx";
    rev = "11ffdcdc9bd65669f1a8dbd3a0362a324dda2e0c";
    sha256 = "sha256-RuQ3piUNLuCqXhf38QQzukeg/PcCVAAQmifym8fZ4vU=";
  };

  buildInputs = [
    zlib
    libxml2
  ];

  propogateBuildInputs = [
    zlib
    libxml2
  ];
# ...

And I’m including it in my project’s CMakeLists.txt like:

# TMX library
find_package(LibXml2 REQUIRED)
find_package(ZLIB REQUIRED)
find_package(tmx 1.10 REQUIRED)

# Target
add_executable(${PROJECT_NAME} ${SOURCES})
target_link_libraries(${PROJECT_NAME} PRIVATE raylib tmx LibXml2::LibXml2
                                              ZLIB::ZLIB)

And I’m essentially wondering if this is the correct way to do it (propogating the build inputs and using cmake to find the library’s dependencies)? I noticed that while raylib has a glfw dependency, I don’t need to use cmake’s find_package for it to compile.

Thanks

2

Looks good to me. propagatedBuildInputs should only be required for dynamically linked libraries (not sure what the default is in nixpkgs). You should always use proper target (alias) syntax including :: whenever possible in target_link_libraries. Those IMPORT targets are provided by find_package.

3

I thtink not.

We are not using propagated dependency attributes very often, since it is contrast to the purpose of using Nix to some extent.

The typical use cases of propagated dependencies are when the use of a library (say tmx) imply the presence of some dependencies (say zlib), which causes the build failure or malfunction of dependent packages. These includes:

  1. The CMake modules provided by tmx assumes the existence of zlib.
  2. The FindTmx CMake function makes zlib’s existence a requirement for finding tmx successfully.