Clinton Stimpson wrote:
If I specify the input (path to test.h.in) & output (path to generated test.h) for the "CMake Rules" build phase, the problem goes away. Maybe we can put all inputs and all outputs in there for generated files in that project? The script (makefile) it calls already has the smarts for which ones really need updating.
I once investigated doing this but never finished. I think it requires a graph algorithm to split rules into maximal groups such that each group has inputs and outputs that are disjoint. Each group gets one "Run Script" build phase.
Or is there a reason we can't just add a build phase for each add_custom_command() ? Possibly too much clutter?
One could try that. I don't know how well build phases scale. There is also the issue that build phases are not per-configuration, so the scripts would have to test $(CONFIGURATION). Currently this is done by using $(CONFIGURATION) to select which Makefile rule to drive. Somewhere I have a patch series that I started last time I investigated this problem. If anyone wants to volunteer to work on it I can send my current patches (they probably don't apply to CVS HEAD now though). IIRC the patches factor out some of the VS IDE custom script code for re-use with Xcode. -Brad _______________________________________________ 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
