Re: [CMake] a dependency nag/bug
Casper Boemann wrote: That used to work during the auto* days, but with cmake it begins to recompile everywhere else too. That means i send a lot of time recompiling stuff i don't need (until later) That's annoying e, too - I vote for this ;-) I don't know how to fix it but it is related to the order of follwoing the dependencies. It would be great to first build the object files of a lib and later (before linking) the other dependant libs. Jan. -- Dipl.-Ing. Jan Woetzel -- University of Kiel Institute of Computer Science and Applied Mathematics Hermann-Rodewald-Str. 3 [room 310] 24098 Kiel/Germany -- Phone +49-431-880-4477 Fax +49-431-880-4054 Mob. +49-179-2937346 -- Url www.mip.informatik.uni-kiel.de/~jw Email [EMAIL PROTECTED] ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] a dependency nag/bug
At 09:05 AM 7/11/2006, Casper Boemann wrote: Hi there I'm developing and compiling KDE using cmake and I really like it and would choose it any day over auto*, but I have this small nag. Say I've changed a headerfile somewhere which in a complete build would cause lots of files to be recompiled and linked. That is fine, but now imagine that I'm using that file in some subdir somewhere. Naturally I'd want to recompile that to test it, but also knowing that nothing else really breaks due to the headerfile change I'd like to cd into that subdir and only recompile the local files. That used to work during the auto* days, but with cmake it begins to recompile everywhere else too. That means i send a lot of time recompiling stuff i don't need (until later) Are there any way to avoid that, because it's really annoying and cuts my development time by at least half. Please cc me as I'm not subscribed to the list ps: Keep up the good work. It's very nice being able to configure the stuff myself and not having to rely on some auto* expert to do it for me -- You can do this: make target/fast Where target is the name of the library or executable that has the .h file you are working on. It will only build that target. Once you get the .h file working, you can run make and build everything else. Currently in CMake 2.4.2 the /fast targets are only in the toplevel makefile. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] a dependency nag/bug
Furthermore could it be made so that the default target in subdirs are fast and that you'd have to write something special (like /slow) to make it like today. Personally I tend not to like having the default option be fast (aka unsafe) although we have debated both sides of it. To me the naïve invocation should be safe and the special invocation should be the unsafe one. So if someone types make in a subdir it should properly build the targets of that subdir including any out of date targets in other directories that they depend on. Make foo should produce a valid result. Make foo/fast will try to build foo without updating other targets that it depends on but it may fail to link or produce an out of date foo depending on the state of those other targets. The /fast says I know what I am doing and I am telling cmake to skip some steps that should normally be done to ensure a properly built target. This is an area we are looking to improve (subdir build performance) and I do not think we are married to any one policy yet. Thanks Ken P.S. the /fast targets are in the subdir Makefile as well. You can do cd foodir; make foo/fast at least in CVS cmake and I'm pretty sure it is in 2.4.2 as well. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] a dependency nag/bug
On Tuesday 11 July 2006 17:56, you wrote: To me the naïve invocation should be safe and the special invocation should be the unsafe one. Ok I wouldn't mind if slow is default as long as: make fast would work anywhere (doing the local target/fast) Actually I ve come across a problem with fast: It doesn't make the subdirectory targets So I would like a medium that does not make sibling dependencies but does make child dependencies (ie stuff from add_subdirectory) medium is actually what I'm looking for. Is that also already possible or are you working on that? -- best regards / venlig hilsen Casper Boemann ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
