[CMake] add_custom_command rerun if arguments change via configuration

James Bigler jamesbigler at gmail.com
Tue Oct 28 17:02:24 EDT 2008


I think I've settled on using configure_file to generate a cmake script that
executes the custom command for each add_custom_command that I care about.
I'll then add a dependency to this cmake script.  This way I can detect the
changes in arguments for each individual command regardless of how the
arguments got filled in.  There are other reasons for doing this (such as
deleting the output file if the command fails), but this issue pushed it
over the edge.

One possible tractable solution for CMake to do this would be similar.  Each
custom command gets its own file somewhere in the CMakeFiles directory or
within the target's build directory.  It then places a dependency on that
file with the custome command's rule.  When CMake configures it can generate
the command and compare it to the one in the file and update the file as
needed.

James

On Tue, Oct 28, 2008 at 2:36 PM, David Cole <david.cole at kitware.com> wrote:

> You imagine correctly. :-)
>
> We'll leave it up to the project CMakeLists authors...
>
> File level dependencies are easy to communicate to make-based or
> Visual-Studio-project-based build systems. Variable value changes, not so
> easy to communicate. But you don't want *all* custom commands to rebuild
> whenever CMakeCache.txt or CMakeLists.txt changes, and some CMake variables
> may be set in included CMake files and then used as custom command args
> later... etc. etc. It is probably a way cool feature, but seriously complex.
>
>
> On Tue, Oct 28, 2008 at 4:00 PM, James Bigler <jamesbigler at gmail.com>wrote:
>
>> I haven't tried that, and I think it could work if I could make sure I
>> kept track of all the possible variables that could go into making the
>> arguments.
>>
>> Is there something fundamental about CMake that would prevent it from
>> detecting this change?  I'm guessing that CMake would have to keep a record
>> of all the custom commands that exist in a project and then compare them
>> upon regeneration.  I imagine that would not be an easy task.
>>
>> James
>>
>>
>> On Tue, Oct 28, 2008 at 1:52 PM, David Cole <david.cole at kitware.com>wrote:
>>
>>> You should be able to configure a file into your binary directory that
>>> references all the option variables of interest and then make a dependency
>>> on that file for your add_custom_command.
>>>
>>> That way, the file will change only if one of the options changes in
>>> cmake and the dependency on it should trigger a re-run of the custom
>>> command...
>>>
>>> Have you tried that?
>>>
>>>
>>> HTH,
>>> David
>>>
>>>
>>>
>>> On Tue, Oct 28, 2008 at 3:45 PM, James Bigler <jamesbigler at gmail.com>wrote:
>>>
>>>> I have a project that makes use of a add_custom_command that generates
>>>> some cpp files from a given input file.  The command can have different
>>>> arguments depending on some CMake OPTION variables.
>>>>
>>>> If I change the option variables from the CMake GUI, configure and
>>>> regenerate the Visual Studio projects, are the add_custom_commands supposed
>>>> to be run again?  Currently they are not.
>>>>
>>>> I would argue that the add_custom_command should be rerun if any of the
>>>> commands change via editing the CMakeLists.txt file or by a configuration
>>>> modification.
>>>>
>>>> Has anyone come up with a mechanism to work around this issue?
>>>>
>>>> CMake: 2.6.2
>>>> VS 2005 (32/64 bit)
>>>> WinXP 64
>>>>
>>>> Thanks,
>>>> James
>>>>
>>>> _______________________________________________
>>>> CMake mailing list
>>>> CMake at cmake.org
>>>> http://www.cmake.org/mailman/listinfo/cmake
>>>>
>>>
>>>
>>
>> _______________________________________________
>> CMake mailing list
>> CMake at cmake.org
>> http://www.cmake.org/mailman/listinfo/cmake
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20081028/4505ed12/attachment-0001.htm>


More information about the CMake mailing list