What's the motivation behind your question?<br><br>(1) Do you want to do this custom command at the end of *every* developer's *every* call to make from your top level?<br>(2) Or do you want to post an automatic build from a build machine when the build is 'done'...?
<br>(3) Something else?<br><br>For (2), I'd recommend using a ctest -S script to drive dashboard builds of your project. Then you could add a test that does what you want or you could add a step to your dashboard script that happens after the build stage is over...
<br><br>For (1) or (3) we'll have to think some more...<br><br>:-)<br>David<br><br><br><div><span class="gmail_quote">On 12/6/06, <b class="gmail_sendername">Eric BOIX</b> <<a href="mailto:eboix@ens-lyon.fr">eboix@ens-lyon.fr
</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Dear David Cole,<br><br>Quoting David Cole <<a href="mailto:david.cole@kitware.com">
david.cole@kitware.com</a>>:<br>> You could add a custom target that depends on all the other targets in your<br>> project.<br>True enough. But for big projects this places a global constraint on all<br>CMakeLists.txt
maintainers who get to update the custom global target<br>dependencies each time they add/delete a new target. One could resolve<br>to some hierarchy of targets instead of a flat approach. Still this<br>sounds heavy and fragile (since it depends on each maintainer). Doesn't it ?
<br><br>For our project we build 30 sub-libraries or libraries (I know this is<br>probably a poor design, nevertheless...), 34 independent binaries (which<br>is reasonable), a user's and programmers guide, the doxygen documentation
<br>not to mention de Ctest part.... The custom global target would be quite<br>complicated. And to that the fact that some targets are only build when<br>some OPTION flags are set...and things get quickly out of control.
<br><br> Thanks anyhow !<br> Yours,<br> Eric Boix.<br></blockquote></div><br>