On 05.08.10 17:05:46, David Cole wrote: > On Thu, Aug 5, 2010 at 2:29 PM, Andreas Pakulat <[email protected]> wrote: > > we're currently hitting what looks like a dependency problem with CMake > > and a custom-command. Unfortunately I couldn't reproduce this so far > > with a small example and it also only happens with one of the targets > > we're building in kdevplatform. This code was recently added, but looks > > the same as another plugin cmake-code and cpp-code wise. > > > > Ok, so here's the deal: We're using a KDE macro to run Qt's uic on our > > .ui files and add the generated header filename into a cmake variable. > > This cmake variable is then passed onto a add_library call (through > > another macro). Now when running make in a freshly created builddir > > using -j3 or so, the rule for generating the ui_xxx.h header is not > > executed before trying to compile the file that uses the header... > > > > I'm using CMake 2.8.2 here currently (or rather current HEAD of the > > release branch) > > > > This problem is only reproduceable after a make clean, once I hit the > > error and do another make -j3 run, the dependencies are proper and hence > > the generation is done. > > > > I've noticed that after the first failing run the depend.make and > > depend.internal files suddenly exist/have content. So it seems that > > cmake generates this info 'too late' and hence doesn't generate the > > ui-header early enough. Whats a bit strange though is that apparently in > > other plugins this stuff works. > > > > One more info: I'm seeing the 'Scanning dependencies of target > > kdevpatchreview' message a lot later than the error when using -k with > > make. And at that point I also see the 'Generating ui_xxx.h' message. > > So, you say it "looks the same" as other plugins that do not demonstrate the > problem... but there must be some differences. > > What are the differences?
Sure, this is the plugin that breaks: http://gitorious.org/kdevelop/kdevplatform/blobs/master/plugins/reviewboard/CMakeLists.txt These two seem to work fine (but that might also just be by accident because they happen to be compiled 'later' and hence their dependency scanning was done already): http://gitorious.org/kdevelop/kdevplatform/blobs/master/plugins/projectmanagerview/CMakeLists.txt http://gitorious.org/kdevelop/kdevplatform/blobs/master/plugins/subversion/CMakeLists.txt > 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. The plugins are all on the same 'level', adding CMAKE_CURRENT_BINARY_DIR to the include_directories didn't help. > Let us know more details... easier to help when looking at code or cmake > output. I'm attaching the make-log, verbose version would probably need uploading somewhere (let me know if you'd like to see that). As I said, if I run make with -k I later on see the dependency-scanning for the kdevreviewboard target and immediately afterwards the generation of the ui_reviewpatch.h file. Andreas -- Fine day to work off excess energy. Steal something heavy.
log.gz
Description: Binary data
_______________________________________________ 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
