[CMake] dependency hell with custom commands and multiple outputs

[David Cole]

The best way to deal with this is probably to have a single "sentinel" or
"stamp" file that gets generated *every* time the command runs. And then
list that file as it's only output that CMake knows about... (But still with
the full list of inputs.)

Does that work?


On Wed, Jan 13, 2010 at 8:26 AM, Michael Wild <themiwi at gmail.com> wrote:

> Hi all
>
> I just ran into an interesting problem. Say I have a custom command that
> produces several files, but only updates them as needed. E.g.
>
> add_custom_command(OUTPUT file1.c file2.c file3.c
>  COMMAND generator file1.inp file2.inp file3.inp
>  DEPENDS generator file1.inp file2.inp file3.inp
>  VERBATIM)
>
> Now, suppose that file2.inp is changed, the build system will run the
> command to update the output. Now, the "generator" program is really smart
> and only updates file2.c. This causes all hell to break lose (at least with
> the GNU Makefile generator on OS X), causing the command to run three times,
> desperately trying to update file1.c and file3.c (because file2.inp is newer
> than them) and then, as it seems, gives up. The thing repeats with every
> invocation of "make".
>
> Now, the "generator" requires all the input files to be processed in one
> step, so I can't split the command as one would usually do. Also, touching
> all the output files after calling "generator" isn't really viable since I'd
> like to prevent unnecessary re-compilation of the produced .c files.
>
>
> Are there any good solutions to this problem?
>
>
> Michael
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100113/600cec1e/attachment.htm>