[CMake] add_custom_command rerun if arguments change via configuration

[James Bigler]

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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20081028/1b2bc352/attachment.htm>