CMake add_custom_command not being run

后端 未结 3 624
北恋
北恋 2020-11-27 04:06

I\'m trying to use add_custom_command to generate a file during the build. The command never seemed to be run, so I made this test file.

cmake_minimum_requir         


        
相关标签:
3条回答
  • 2020-11-27 04:11

    The problem with two existing answers is that they either make the dependency global (add_custom_target(name ALL ...)), or they assign it to a specific, single file (set_property(...)) which gets obnoxious if you have many files that need it as a dependency. Instead what we want is a target that we can make a dependency of another target.

    The way to do this is to use add_custom_command to define the rule, and then add_custom_target to define a new target based on that rule. Then you can add that target as a dependency of another target via add_dependencies.

    # this defines the build rule for some_file
    add_custom_command(
      OUTPUT some_file
      COMMAND ...
    )
    # create a target that includes some_file, this gives us a name that we can use later
    add_custom_target(
      some_target
      DEPENDS some_file
    )
    # then let's suppose we're creating a library
    add_library(some_library some_other_file.c)
    # we can add the target as a dependency, and it will affect only this library
    add_dependencies(some_library some_target)
    

    The advantages of this approach:

    • some_target is not a dependency for ALL, which means you only build it when it's required by a specific target. (Whereas add_custom_target(name ALL ...) would build it unconditionally for all targets.)
    • Because some_target is a dependency for the library as a whole, it will get built before all of the files in that library. That means that if there are many files in the library, we don't have to do set_property on every single one of them.
    • If we add DEPENDS to add_custom_command then it will only get rebuilt when its inputs change. (Compare this to the approach that uses add_custom_target(name ALL ...) where the command gets run on every build regardless of whether it needs to or not.)

    For more information on why things work this way, see this blog post: https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/

    0 讨论(0)
  • 2020-11-27 04:12

    Add the following:

    add_custom_target(run ALL
        DEPENDS hello.txt)
    

    If you're familiar with makefiles, this means:

    all: run
    run: hello.txt
    
    0 讨论(0)
  • 2020-11-27 04:20

    The add_custom_target(run ALL ... solution will work for simple cases when you only have one target you're building, but breaks down when you have multiple top level targets, e.g. app and tests.

    I ran into this same problem when I was trying to package up some test data files into an object file so my unit tests wouldn't depend on anything external. I solved it using add_custom_command and some additional dependency magic with set_property.

    add_custom_command(
      OUTPUT testData.cpp
      COMMAND reswrap 
      ARGS    testData.src > testData.cpp
      DEPENDS testData.src 
    )
    set_property(SOURCE unit-tests.cpp APPEND PROPERTY OBJECT_DEPENDS testData.cpp)
    
    add_executable(app main.cpp)
    add_executable(tests unit-tests.cpp)
    

    So now testData.cpp will generated before unit-tests.cpp is compiled, and any time testData.src changes. If the command you're calling is really slow you get the added bonus that when you build just the app target you won't have to wait around for that command (which only the tests executable needs) to finish.

    It's not shown above, but careful application of ${PROJECT_BINARY_DIR}, ${PROJECT_SOURCE_DIR} and include_directories() will keep your source tree clean of generated files.

    0 讨论(0)
提交回复
热议问题