add_custom_custom multiple output and multiple directories.

Usage
1

Hi,

We have a situation where for each libraries of our project we need to call an executable that generates:

  • a source file that is compiled and included in the library
  • an auxiliary pcm file (similar to a C++ precompile module files)

As input to each invocation of the executable we have

  • The header files of the library and a steering file
  • The generated pcm files corresponding all the libraries the ‘current’ library depends on.

To do so we use something like:

add_custom_command(
   OUTPUT dict${modulename}.cxx ${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/${modulename}.pcm
   COMMAND ${generator} ${generator_args}
   IMPLICIT_DEPENDS
      CXX ${full_path_to_header_1}
      CXX ${full_path_to_header_2}
      etc ...
   DEPENDS
      ${full_path_to_header_1}
      ${full_path_to_header_2}
      etc ...
      ${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/${dependent_modulename_a}.pcm
      ${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/${dependent_modulename_b}.pcm
      etc ...
)

This has two majors problems:

  1. With Ninja support IMPLICIT_DEPENDS is (not yet?) implemented and thus the command is not re-run if one of the indirect header file inclusion is changed
  2. With Unix Makefiles IMPLICIT_DEPENDS work as intended for the header file depedencies
    BUT it does not properly support the dependencies on the secondary OUTPUT of the add_custom_command (the pcm files).

The exact mechanism of the odd behavior in 2. is described at https://gitlab.kitware.com/cmake/cmake/-/issues/27521 ( GitHub - pcanal/cmake_custom_command: Demonstrate a potential issue in cmake_custom_command ). In the issue @craig.scott mentions that this is not surprising as the documentation hints that ‘cross directory’ dependencies involving the add_custom_command is not really supported and instead of the pcm files the downstream custom command should be depending on the whole dependent library. This solution feels a bit odd (as the library is not an actual input to the custom command) and may increase (a bit) the serialization of the build process (now each generation step needs to wait until the full libraries it depends on are built instead of ‘just’ waiting for the corresponding generation steps). In the issue, I mention a fix to the files produced by Unix Makefiles generator to enhance the support IMPLICIT_DEPENDS to work correctly in the case I have.

So two questions:

  1. Would there be any objections to change proposed in the issue ? (i.e. I would prepare a patch implementing the suggestion if that is helpful).

  2. Is there a way to emulate the support for IMPLICIT_DEPENDS with the Ninja generator (and/or is support for it planned)?

Thanks,
Philippe