|
Furious activity in Digikam, KmPlot and amaroK. Compile and linking fixes for applications in /trunk with CMake. Multi-platform porting fixes. KSmileTris is removed from /trunk/KDE/kdegames/.
|
The upcoming KDE 4 era heralds many changes, and one of those is the introduction of a new build system: CMake. People following KDE 4 development may at this point be asking what happened to SCons, the build system previously championed as the solution to the current autotools-based build system kludge. Well, with the understanding that CMake is not just a renamed SCons, KDE 4 must have chosen a different solution somewhere along the way...
|
Alexander Neundorf explains the reasoning behind the change:
|
scons was chosen at akademy, and people started to work on it.
But after months of work we ended up basically with a fork of scons.
So apparently scons wasn't the best tool for the job.
...
CMake needed some enhancements mainly for the windows stuff (we are probably the first project which uses mingw heavily). The cmake developers have been very supportive for KDE, they are on the buildsystem mailinglist and fixed the issues we found within days. They want cmake to become the buildsystem for KDE 4.
|
|
Thomas Nagy clarifies:
|
|
Not a fork but an experimental branch.
|
|
Followed by a round-up from Thiago Macieira:
|
We had basically no relationship with the scons maintainers. None of our changes were applied upstream.
One of the reasons, at least, was to maintain compatibility with an old Python version. By dropping that compatibility, we made some progress, but created a fork.
|
|
Of course, the introduction of any significant change is going to take a while to get used to, as Aaron Seigo noted:
|
the introduction of cmake, however, has redefined "waste of time" for me.
...
between how much slower cmake is and the constant breakages that i have no idea how to fix (like the NOGUI in kdesu/kdesud/CMakeLists.txt not working, even though i have the latest cmake modules installed from kdelibs that seem to include something about it) i really, really, really hope that it improves dramatically over the next month. we don't need a build system holding us back. i understand the need for something better than autotools, but in my book the baseline for "better" is "actually builds reliably". meh.
|
|
However, CMake does have at least some supporters within the KDE camp. Boudewijn Rempt likes it for, amongst other things, its ability to compile KOffice trunk, whilst Adriaan de Groot comments:
|
Aaron's right in some ways. With auto*, there is this huge collected cloud of knowledge about how things work and you can shout out on lots of IRC channels when something's wrong. Anyway, it's all shell script and anyone can write shell script, right? Therein lies both the power and the failing of auto* -- it's hard to write correct shellscript (svn log doxygen.sh for my stumblings), but whacking something into shape isn't that hard.
With CMake, I get the feeling that there's only a very few gurus who know what is going on (Alex, David, and of course William Hoffmann on -core-devel). Whining often leads to fixes of a mysterious nature. But waiting for osmosis to somehow bring enough knowledge to developers is a slow process. The wiki page has some information, but it's mostly about using CMake under ideal conditions, as opposed to fixing it when it's broke.
...
I believe Aaron's point on CMake is that a build system shouldn't get in the way, and if CMake breaks right now and keeps him from working on whatever it is he does, those are valuable wasted hours. autofoo had progressed to a point that it didn't regularly get in the way of developers on KDE's UNIX-like platforms. CMake does get in the way, since it's still being broken. For the -- presumably many -- people who do not want to be build-system guru's, the system just has to work. That goes double for external tools that use the build system, like Coverity's static checking.
Now I'm done being annoyed for CMake getting in the way, though, I can get on with loving it for the things that it does right.
|
|
...and finally, Aaron Seigo comes over to the CMake side:
|
so... moving away from autohell was probably a good idea. cmake was probably our best choice. and it's currently a painful process. i don't like losing days of productivity to it, and i really don't like the thought of others going through the same. but...
...i'm fairly confident that it'll work out in the end; i have great faith in the people who work on this project. we're not "in the end" yet, more in the middle. and along the way i think it is healthy to discuss what is working and what isn't working along the way.
|
|
The acceptance and adoption of CMake can be seen with the many commits this week regarding the porting of existing KDE apps to KDE 4. See below for specific examples of this activity.
|
Tom Albers announces version 0.6.0 of RSIBreak, a utility to help prevent Repetitive Strain Injury:
|
About RSIBreak
Repetitive Strain Injury is an illness which can occur as a result of working with a mouse and keyboard. This utility can be used to remind you to take a break now and then. It will show you a random picture from a collection you can configure yourself for a configurable duration at a configurable interval.
You can use these breaks to do some stretch exercises for example, or as a reminder to walk away from the computer for a while.
RSIBreak will sit in your system tray and when it is time for a break it will show you the picture full screen. All timings can be set by clicking with the right mouse button on the icon in the system tray.
Version 0.6.0 Changelog:- Extensive amount of statistics.
- Colors to indicate how far away you are from a break in the tooltip
- libxss for the idle detection is a no longer optional, it is required.
- RSIBreak remembers the timer states when you quit. It can restore the timers if you restart RSIBreak afterwards in a short timeframe. This is handy for rebooting (for those zealots who believe rebooting solves problems).
- Bug fixes:
- For Gnome there were two Quit entries in the context menu.
- Welcome message on first launch was incorrect.
- Compiles with KDE 3.3 and probably with gcc 2.9x.
- Memory leak while querying idle time.
- Some buddies in the setup were not set.
- Some i18n calls in the setup were not correct.
- Clear focus from buttons to prevent accidental closure of a break.
To find out more information about RSIBreak, and to download packages for your distribution, go to http://www.rsibreak.org
|
|
Congratulations to Thomas Zander, who managed to close a massive 91 bugs in KOffice this week. As he says:
|
|
So, if you want to get your name in the new commit-digest, take a look at the junior jobs page and help us out!
|
|
I couldn't agree more!
|
![[*]](/images/standard/bugfixes)
![[*]](/images/standard/features)
![[*]](/images/standard/other)
![[*]](/images/standard/optimise)
![[*]](/images/standard/security)