<div class="gmail_quote">On Thu, Aug 5, 2010 at 2:29 PM, Andreas Pakulat <span dir="ltr"><<a href="mailto:apaku@gmx.de">apaku@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi,<br>
<br>
we're currently hitting what looks like a dependency problem with CMake<br>
and a custom-command. Unfortunately I couldn't reproduce this so far<br>
with a small example and it also only happens with one of the targets<br>
we're building in kdevplatform. This code was recently added, but looks<br>
the same as another plugin cmake-code and cpp-code wise.<br>
<br>
Ok, so here's the deal: We're using a KDE macro to run Qt's uic on our<br>
.ui files and add the generated header filename into a cmake variable.<br>
This cmake variable is then passed onto a add_library call (through<br>
another macro). Now when running make in a freshly created builddir<br>
using -j3 or so, the rule for generating the ui_xxx.h header is not<br>
executed before trying to compile the file that uses the header...<br>
<br>
I'm using CMake 2.8.2 here currently (or rather current HEAD of the<br>
release branch)<br>
<br>
This problem is only reproduceable after a make clean, once I hit the<br>
error and do another make -j3 run, the dependencies are proper and hence<br>
the generation is done.<br>
<br>
I've noticed that after the first failing run the depend.make and<br>
depend.internal files suddenly exist/have content. So it seems that<br>
cmake generates this info 'too late' and hence doesn't generate the<br>
ui-header early enough. Whats a bit strange though is that apparently in<br>
other plugins this stuff works.<br>
<br>
One more info: I'm seeing the 'Scanning dependencies of target<br>
kdevpatchreview' message a lot later than the error when using -k with<br>
make. And at that point I also see the 'Generating ui_xxx.h' message.<br>
<br>
Andreas<br>
<br>
--<br>
Good news from afar can bring you a welcome visitor.<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 <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: <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>
</blockquote></div><br><div><br></div><div>So, you say it "looks the same" as other plugins that do not demonstrate the problem... but there must be some differences.</div><div><br></div><div>What are the differences?</div>
<div><br></div><div>Can you re-name things in yours to the same names as one that works, and then do a "diff" ...?</div><div><br></div><div>Or just send a few code snippets along that look different?</div><div><br>
</div><div>There are lots of folks doing Qt stuff with CMake, and I do not recall hearing of anything like this recently. I'd think it should work, so there must be some small difference in your CMakeLists.txt file (or something it includes) that is triggering this issue.</div>
<div><br></div><div>Let us know more details... easier to help when looking at code or cmake output.</div><div><br></div><div>Thanks,</div><div>David</div><div><br></div>