Yes I knew for the GENERATED option. <br><br>This solution is a good work-around but still, it would be nice if CMake could handle the situation this way:<br><br># Generate Java / XML binding files <br>add_custom_command(<br>
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/src/*.java<br> COMMAND ${JAVA_PATH}/xjc ${CMAKE_SOURCE_DIR}/xsd/*.xsd<br> DEPENDS ${CMAKE_SOURCE_DIR}/xsd/*.xsd<br> COMMENT "Invoking xjc to generate Java binding files")<br>
<br>The OUTPUT, DEPENDS could handle regex strings.<br><br>What do you think?<br><br>Cheers,<br><br><div class="gmail_quote">2010/1/18 Michael Wild <span dir="ltr"><<a href="mailto:themiwi@gmail.com">themiwi@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Yes, it worked for me.<br>
<br>
But, as I already mentioned, be careful to mark the files as GENERATED and add them to the ADDITIONAL_MAKE_CLEAN_FILES directory property. One caveat is, however, that if you delete any of the output files, CMake won't regenerate them unless you also delete the stamp file (or that one is out-of-date).<br>
<br>
Also, if your custom output depends on compiler flags, you'll probably want to include ${CMAKE_CFG_INTDIR} in the output-paths to support multi-configuration IDE's. This can be tricky to do if you use wrapper-cmake scripts, because the IDE's expand the variable at build-time and only if they see it on the command line, so you have to make sure it shows up there...<br>
<font color="#888888"><br>
Michael<br>
</font><div><div></div><div class="h5"><br>
On 18. Jan, 2010, at 15:56 , Romain CHANU wrote:<br>
<br>
> Hi Michael.<br>
><br>
> I got the same situation here. I am using a command which outputs a lot of<br>
> files (>100 files).<br>
><br>
> Have you tried what David is suggesting?<br>
><br>
> Thank you to update us.<br>
><br>
> Cheers,<br>
><br>
> 2010/1/13 Michael Wild <<a href="mailto:themiwi@gmail.com">themiwi@gmail.com</a>><br>
><br>
>> Hmmm, thought of something like that myself, but am not sure whether<br>
>> dependencies will be handled correctly. Of course, I'll have to label the<br>
>> products as GENERATED and add them to ADDITIONAL_MAKE_CLEAN_FILES. Will<br>
>> give it a try...<br>
>><br>
>><br>
>> Michael<br>
>><br>
>><br>
>> On 13. Jan, 2010, at 16:17 , David Cole wrote:<br>
>><br>
>>> The best way to deal with this is probably to have a single "sentinel" or<br>
>>> "stamp" file that gets generated *every* time the command runs. And then<br>
>>> list that file as it's only output that CMake knows about... (But still<br>
>> with<br>
>>> the full list of inputs.)<br>
>>><br>
>>> Does that work?<br>
>>><br>
>>><br>
>>> On Wed, Jan 13, 2010 at 8:26 AM, Michael Wild <<a href="mailto:themiwi@gmail.com">themiwi@gmail.com</a>> wrote:<br>
>>><br>
>>>> Hi all<br>
>>>><br>
>>>> I just ran into an interesting problem. Say I have a custom command that<br>
>>>> produces several files, but only updates them as needed. E.g.<br>
>>>><br>
>>>> add_custom_command(OUTPUT file1.c file2.c file3.c<br>
>>>> COMMAND generator file1.inp file2.inp file3.inp<br>
>>>> DEPENDS generator file1.inp file2.inp file3.inp<br>
>>>> VERBATIM)<br>
>>>><br>
>>>> Now, suppose that file2.inp is changed, the build system will run the<br>
>>>> command to update the output. Now, the "generator" program is really<br>
>> smart<br>
>>>> and only updates file2.c. This causes all hell to break lose (at least<br>
>> with<br>
>>>> the GNU Makefile generator on OS X), causing the command to run three<br>
>> times,<br>
>>>> desperately trying to update file1.c and file3.c (because file2.inp is<br>
>> newer<br>
>>>> than them) and then, as it seems, gives up. The thing repeats with every<br>
>>>> invocation of "make".<br>
>>>><br>
>>>> Now, the "generator" requires all the input files to be processed in one<br>
>>>> step, so I can't split the command as one would usually do. Also,<br>
>> touching<br>
>>>> all the output files after calling "generator" isn't really viable since<br>
>> I'd<br>
>>>> like to prevent unnecessary re-compilation of the produced .c files.<br>
>>>><br>
>>>><br>
>>>> Are there any good solutions to this problem?<br>
>>>><br>
>>>><br>
>>>> Michael<br>
>>>> _______________________________________________<br>
>>>> Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
>>>><br>
>>>> Visit other Kitware open-source projects at<br>
>>>> <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
>>>><br>
>>>> Please keep messages on-topic and check the CMake FAQ at:<br>
>>>> <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
>>>><br>
>>>> Follow this link to subscribe/unsubscribe:<br>
>>>> <a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
>>>><br>
>><br>
>> _______________________________________________<br>
>> Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
>><br>
>> Visit other Kitware open-source projects at<br>
>> <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
>><br>
>> Please keep messages on-topic and check the CMake FAQ at:<br>
>> <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
>><br>
>> Follow this link to subscribe/unsubscribe:<br>
>> <a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
>><br>
<br>
</div></div></blockquote></div><br>