View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002059CMakeCMakepublic2005-07-19 15:182005-08-09 09:53
ReporterAlex Neundorf 
Assigned ToKen Martin 
PrioritylowSeveritymajorReproducibilityalways
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0002059: cmake sometimes misses to rebuild stuff
DescriptionHi,

sorry for the very vague summary.
With makefile generator v3 it seems that under certain circumstances the makefiles don't recognize that they have to dive into a subdir since there new targets or subdirs have been added.
I tried to build a simple testcase, but didn't succeed until now.

It happened while trying to build kdelibs/.
I added another subdir in kdelibs/kdecore/. When running make again, it didn't go into kdelibs/kdecore/ but continued where it stopped before (much further than kdecore).
Executing make manually in kdelibs/kdecore/ correctly built the newly added subdirectory.

Hopefully I'll be able to generate a simple testcase.
Might it be related to the fact that the target ADD_LIBRARY(kdecore ${srcs}) has the same name as the directory it lives in (kdelibs/kdecore/) ?

Bye
Alex
TagsNo tags attached.
Attached Fileslog file icon make.log [^] (41,913 bytes) 1969-12-31 19:00
txt file icon CMakeLists.txt [^] (4,532 bytes) 1969-12-31 19:00 [Show Content]
? file icon CMakeLists.txt.2 [^] (5,351 bytes) 1969-12-31 19:00
? file icon CMakeLists.txt.3 [^] (996 bytes) 1969-12-31 19:00

 Relationships

  Notes
(0002697)
Bill Hoffman (manager)
2005-07-19 16:57

This sounds like a global cmake is not being done when a cmakelist file is changed. To add a subdir, you would have to modify an existing cmakelist file, which should cause cmake to re-run.
(0002701)
Ken Martin (developer)
2005-07-20 09:19

At the top level of the binary tree there is a file called Makefile.cmake. In that file contains a list of all file that if changed require a complete rerun of cmake. (this is stored in the CMAKE_MAKEFILE_DEPENDS variable) All of your current CMakeLists.txt files should be in that list. If you add a new subdirectory you would have to modify one of those files. The next time you do a make, a full cmake will be run and the new subdir should be added in. Hopefully that is all working.
(0002752)
Alex Neundorf (developer)
2005-08-01 16:55

I got it here in a reproducable state.
In kdelibs/dcop/ looks like this:
ADD_SUBDIRECTORY(KDE-ICE)
ADD_EXECUTABLE()
ADD_LIBRARY()
ADD_SUBDIRECTORY(dcopidl)

It seems that the generated makefiles don't go into dcopidl.
I attached kdelibs/CMakeLists.txt, kdelibs/dcop/CMakeLists.txt, kdelibs/dcop/dcopidl/CMakeLists.txt and the output from make. After linking dcopserver_shutdown it proceeds with kdelibs/kdefx/.

If you need more info or can give me some more ideas how to find out what's going wrong, let me know.

Alex
(0002823)
Ken Martin (developer)
2005-08-08 14:36

There is an error in your build. So how do you know it will not eventually go into dcopidl if there is a build error? Maybe I'm missing something here :-) Please let me know if I am not understanding the problem. Just because dcopidl it is a subdir of dcop and comes after KDE-ICE in the CMakeLists file doesn't mean anything about when it will get built by make. The only thing that determines the order in which targets get built is the intertarget dependencies. If you add a new target somewhere in your project that doesn't depend on anything and nothing depends on it, then you have no idea when it will be built. It is strickly up to your systems implementation of make to decide when to build it. It could be built first or last or somewhere in the middle. If the build error in your log is realted to something in dcopidl not being built yet then my guess it that there is a missing dependency between the two targets. Either way let me know and we'll get to the bottom of this :-)

Thanks
Ken
(0002828)
Alex Neundorf (developer)
2005-08-08 16:56

Ok, it seems I understand what's going on.
When executing "make all" in kdelibs/, it seems at first all the libraries are built, and after this the executables (at least kdelibs/dcop/dcopidl/dcopidl.dir/all appears in line 3165, while kdelibs/dcop/DCOP.dir/all appears already in line 115 of Makefile2.
Now the problem is that dcopidl is used in some custom commands as a tool and so it has to be built before some other stuff.
I didn't explicitely add a dependency to dcopidl to these rules (which use dccopidl).
When executing "make all" in kdelibs/dcop/ it first builds all libs there and then the executables in the subdirs (how I would expect it and how it would work with normal recursive makefiles).
So, how can I force that these executables are built earlier ?
The custom commands look like this:

ADD_CUSTOM_COMMAND(OUTPUT ${_kidl}
  COMMAND ${CMAKE_BINARY_DIR}/bin/dcopidl
  ARGS ${CMAKE_CURRENT_SOURCE_DIR}/${_current_FILE} > ${_kidl}
  DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/${_current_FILE} )

I tried adding "${CMAKE_BINARY_DIR}/bin/dcopidl" to the DEPENDS part of the custom command and this seems to have the desired effect.
Is this the recommended way to enforce the build order ?

Alex
(0002829)
Brad King (manager)
2005-08-08 17:37

Adding a dependency directly on the generator executable target is fine. Note that in order to work for Visual Studio and XCode generators you need to take into account the build configuration type when constructing the name of the executable for the COMMAND setting. See this FAQ entry:

http://www.cmake.org/Wiki/CMake_FAQ#How_can_I_generate_a_source_file_during_the_build.3F [^]
(0002832)
Ken Martin (developer)
2005-08-09 09:53

All you should need to do is add a dependency to the executable target and I do not think you need to fully specify it in general. There is quite a bit of code in CMake to handle this. Usually we just add the name of the target and CMake figures out the rest. So if your exe is dcopidl then just add dcopidl as a dependency for your custom command. CMake should recognize it as a target and make the dependency on the target. If this doesn;t work reopen the bug and we'll look into it more.

Thanks
Ken


 Issue History
Date Modified Username Field Change


Copyright © 2000 - 2018 MantisBT Team