ninja: Entering directory `build'
ninja explain: output CMakeFiles/SameDest doesn't exist
ninja explain: CMakeFiles/SameDest is dirty
ninja explain: SameDest is dirty
Obviously, the reason that causes rebuilding every time is CMakeFiles/SameDest does not exist, because my custom target does not output to that directory.
I manage to have a simple workaround by setting a link:
I’m not sure what phony means, but I guess that is why in the case ninja does not try to inspect whether CMakeFiles/SameDest-fin is valid, and thus does not trigger a rebuild.
And that leads to the idiomatic way to do this in CMake: create a custom command to produce the output you want (let’s call it X), and then create a custom target that will DEPENDS on the custom command’s output (X). The target will always build, but since it won’t have a COMMAND, all it will do is bring its dependencies (i.e. X) up to date. If X doesn’t exist or is out of date, the custom command will build it. If X is up to date, nothing happens.
The linked discourse topic is just a question of some person, there’s no guideline in there.
That person already used a custom command, which you didn’t. And his cause of rebuilds is most likely the glob for source files, which seems to also include regularly changed .DS_Store files from MacOS.
Please rely on the CMake documentation:
The first paragraph of add_custom_target explains the behavior of always building and refers to add_custom_command as alternative.
The second paragraph of add_custom_command adds more details and even links an example where that combination is used.
The first paragraph of add_custom_target explains the behavior of always building and refers to add_custom_command as alternative.
I’ve already checked that. But I don’t think ‘always building’ equals to ‘force building’. The latter should be built whenever some changes have been made, while the latter suggests unconditional rebuild.
In my case, add_custom_target with specifying COMMAND will generate files under CMakeFiles/<target_name>, and if user command outputs elsewhere, that directory is never created and thus causing an unwanted force building even the source file is unchanged.
The second paragraph of add_custom_command adds more details and even links an example where that combination is used.
Thanks for the link, it does describe the joint use of add_custom_command and add_custom_target, though the example is not aimed for it. Honestly I only learned how to prevent race condition after reading that, but not creating a custom target without COMMAND.
I’m still quite new to CMake, so please correct me if I’m wrong. Thanks!
You have to think about, how all build tools work.
A build rule defines, how an output file is created, and which files are needed (so called dependencies).
The major task of build tools is to avoid executing all build rules, otherwise you could have written a shell script.
Makes usually do this by comparing the time stamp of the output file, with all dependencies. And only if a dependency is newer than the output, a rebuild of that rule is necessary. Ninja has some advanced techniques.
As add_custom_target explains, it has no output file by definition. In that case, a make cannot compare time stamps, it has to always execute the build rule.
So by definition it is always built, when the target is called.
For me, the word “force” implies, that you want to force the execution, even if it could be avoided. This is usually the case if you use e.g. make -B to force the re-creation of object files and executeables, even if they are up-to-date.
The -k flags just tell the tools to not stop scheduling new tasks when a command fails (those depending on the failed task are not scheduled however). Perhaps you mean the make -B flag (ninja has no equivalent)?
There’s no “forcing” done though. An add_custom_target(COMMAND) has no output and is therefore “never up-to-date” and needs to be run whenever the target is requested. Using the ALL flag makes this happen for “default” builds, but otherwise can be used to do things like a “deploy” command that always tries to deploy (whatever that means for the project at hand).
@ben.boeckel
It was too late at night. My mind mixed up the options. I usually use OpusMake where it’s -a and I knew it is a different letter on gnumake and picked the wrong one.
And that what I tried to explain, that only something like -B can be named as forced, but add_custom_target is simply built always by design.