[CMake] Dependency bug in cmake with a custom-command

[Andreas Pakulat]

On 05.08.10 17:05:46, David Cole wrote:
> On Thu, Aug 5, 2010 at 2:29 PM, Andreas Pakulat <apaku at gmx.de> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: log.gz
Type: application/octet-stream
Size: 3440 bytes
Desc: not available
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100805/6c69152a/attachment.obj>