AUG
10
2006

Speeding up development

If you develop like me, you will most likely have a lot of 'change source' 'compile' 'test' roundtrips. Each roundtrip will need a 'make install' to actually be able to see your changes. So, after we optimized linking by dumping libtool, installing is the place to look.
In KDE4 we use cmake, and its slow on installing. See this bugreport. Apparently someone had the right idea to not install things twice, but for some reason that got implemented using a diff. So my 6Mb kwordprivate.so gets ready byte by byte and compared with the installed one. Ugh, that can't be fast if they are indeed the same.

So, I sat down over lunch today and extended my unsercmake app to no longer call the cmake install target, but do it ourselves. CMake makes it easy because it basically writes out a script with source and target lines. So it really was just a couple of hours hacking.
For finding out what I have to actually install I did what I think is the norm; check modified date and filesize and determine on those grounds if the installed one is old or incorrect.

Doing a unsercmake install twice now makes the second one return immediately. Which saves me quite some time and makes me even more productive :)

Oh, and at the same time I moved the 'install lib' to be immediately after linking. Solving another annoyance I had where you have to wait for everything to be compiled and installed before you can start your app to see the changes.

Please download and test. I won't claim this is perfect; but more people that like these changes and tell the cmake developers will help us all to get better tools. For now, I like the fact that I have a simpler to use and more powerful tool. Oh, don't forget to type: unsercmake --help

Download the script here

Comments

You know, you probably could have implemented that into cmake itself in less time than it took to hack on your script. It's not like the source is hidden or anything, and it's very well done C++ so there shouldn't be any problem understanding it. If you'd done that and submitted a patch, that would be one less thing to worry about, right?


By lovelace at Fri, 08/11/2006 - 00:47

The CMake developers made it perfectly clear that the issues I have solved in my own way are not actually bugs and in the opinion of the CMake developers, the /fast option fixes all problems.

Without the maintainers recognizing the issue as a problem, how good are the chances of them accepting a patch that fundamentally changes behavior?


By Thomas Zander at Fri, 08/11/2006 - 12:18

Hi,

the situations is as this:
currently a "make install" generated by cmake works without errors. It behaves differently than what you know from autotools. This is in itself not a bug.

Making it run faster is an optimization. If this means that some files will be copied although they don't really have to other people might consider this a bug.
That the install target at first completely does "make all" and afterwards starts to install everything is not a bug. I mean, which error does it cause ?
Others could even argue that you just have to adjust your directory tree a bit to solve this issue, e.g.
instead of

lib/
lib/plugin1/
lib/plugin2/
lib/plugin3/

organize it as:

lib/
plugins/
plugins/plugin1/
plugins/plugin2/
plugins/plugin3/

Then you can "make install" in lib/ and won't have to wait until all plugins are compiled.
Anyway, I'll try to write a patch for cmake so that you can "make install/local" or something like this and it will not install the stuff subdirectories, but only from the current directory.

Implementing something so that you can make it behave a bit differently is definitely a feature request, not a bug report (ok, both end up in a "bug tracker").

So your issues are definitely right in the bug tracker, but some of them are optimizations, some are wishlist items, and some are real bugs.

How many bugs did you file against gcc because it takes ages to compile KDE ?

Bye
Alex


By Alexander Neundorf at Fri, 08/11/2006 - 20:39