|
NOV
14
2008
|
How to get the CMake version you needKDE svn trunk requires [http://www.cmake.org CMake] 2.6.2 since last week. Version 2.6.2 has been released just a few weeks ago, so maybe there are not yet packages for all distros. So how do you get CMake 2.6.2 ? Of course you can get the sources (from cvs or as source package from http://www.cmake.org/files/ ) and build it yourself. But you can also get away with less work and just use the binary CMake packages provided by [http://www.kitware.com Kitware]. You think they won't work on your Linux distribution ? I can tell you, they most probably will. At least I haven't found an x86 Linux box yet where they don't work. So, here's how you can do it $ cd $ wget http://www.cmake.org/files/v2.6/cmake-2.6.2-Linux-i386.tar.gz $ tar -zxvf cmake-2.6.2-Linux-i386.tar.gz And now you are already ready to use it: $ cd src/my_project $ mkdir build $ cd build $ ~/cmake-2.6.2-Linux-i386/bin/cmake ..
Btw., this way it is also very easy to have multiple different versions of CMake on your system. In http://www.cmake.org/files/ you can still get CMake 2.4.x, 2.2.x and back until the ancient version 1.2. Alex |
 |
Comments
Fix it
I really dislike this approach. In the same way people don't want to recompile kernel, Xorg, Mesa or libc every time they compile KDE I really, really, really don't want to compile and install by hand build systems to build KDE. It's kinda one of the reasons I use a distro - to not have to build everything by hand.
And honestly I don't understand why we can't keep CMake working between minor releases. It's really weird that 2.6.0 and 2.6.2 are so incompatible that kde just outright refuses to compile with 2.6.0.
Re: Fix it
Then you're using the wrong distro. ;-) See comment about Fedora 9 above.
Great
Here I was not feeling like compiling a new build system but it turns out that all I have to do is reinstall my entire machine and resetup everything I have and the problem will be solved! Man, thank god you were around, because advice this good doesn't just come around...
Fix what ?
I already wrote a reply yesterday, but it seems I forgot to actually hit "Save" :-/
So, second try.
> It's really weird that 2.6.0 and 2.6.2 are so
> incompatible that kde just outright refuses to compile
> with 2.6.0.
CMake 2.6.2 is backwards compatible to 2.6.0, 2.6.0 is not forward compatible to 2.6.2. Do you know any software which is already now compatible to the features of future versions of the same software ?
KDE 4.0.x and 4.1.x require CMake >= 2.4.5, hopefully KDE 4.2 and 4.3 will require >= 2.6.2.
I know that right now CMake 2.6.2 is not yet available as distro package. I understand that you don't like that and I always try to avoid the situation that we require a version of CMake which is not yet available from most distros by default (check e.g. the discussion before requiring 2.4.5), but this time I didn't really have another option.
Also I announced it 3 weeks in advance and there were basically no complaints.
In order to make installing that version easier I posted this blog entry. This way it is really easy to install cmake cleanly separated from the rest of your system, so it doesn't mess in any way with your packaging system. Just remove the directory if you don't want it anymore.
CMake 2.6.0 was a new major release of CMake, coming with a lot of new features, and we should use these features. "Should" as in "if we don't, distros will maintain huge patches and ship something we didn't develop".
As with every new major release of a software, it shouldn't be completely surprising that once a lot of people start using it, bugs are found. This was also the case with CMake 2.6.0, the feature to define the link interface for libraries had issues and also the support for searching FooConfig.cmake files didn't consider the lib64/ directories. There were more minor things, but these two are the important ones.
In general, it would be possible to write our cmake files in such a way that they still require only 2.4.5 but make use of the new features of newer versions of cmake if available.
But this has downsides, and I'd say the downsides outweight the advantages. What are the downsides ? First, our scripts would have to handle the different versions, i.e. there would have to be either if()s or wrapper macros to handle the differences. This would make our build scripts more complex and harder to understand and maintain. Additionally if there are build problems, we would have to find out which version he is actually running and then fix the support for that version again.
If somebody would be working on this fulltime it would be possible, maybe. But I'm doing this only in my spare time after work, I'm afraid this would be more than I can handle with my limited time.
Also, if we would keep compatibility to 2.4.5, we would not be able to do some clean up work, again our scripts would become harder to understand.
Also consider that if we would have stayed with 2.4.5, with time more and more people would run 2.6.x anyway, and I'm completely sure that from time to time it would happen that one of them would add some cmake code to our scripts which is new since 2.6.0, and would this way unknowingly break the build for those still running 2.4.x. By forcing a newer cmake version we avoid this problem.
So, what was not working in 2.6.0, has indeed been fixed in 2.6.2, and we require this fixed version now.
Alex
KDE
"Do you know any software which is already now compatible to the features of future versions of the same software ?"
I sure do. It's called KDE. I can compile KDE that depends on Qt 4.4 with Qt 4.4.0, Qt 4.4.1, Qt 4.4.2, Qt 4.4.3 and so on. The same applies to Mesa, Xorg, libc and so. Everything in fact. Everything except CMake that is.
Not even mentioning that if we do require new software we just disable features if an older version is present not just outright refuse to compile at all.
"So, what was not working in 2.6.0, has indeed been fixed in 2.6.2, and we require this fixed version now."
That's not the way minor releases of any software work! That's exactly against the minor releases of any software. Otherwise what's stopping anyone else from making KDE outright refuse to compile on any minor release of Mesa, Xorg, libc or any other library?
Release knowingly non-working software ?
> I can compile KDE that depends on Qt 4.4 with Qt 4.4.0, Qt 4.4.1, Qt
> 4.4.2, Qt 4.4.3 and so on.
Once, it's released, usually yes.
You know, we have something called qt-copy in svn, and from time to time we depend on the most recent version of qt-copy, otherwise the code just doesn't build. I think that's a very similar situation.
So, let's say Qt 4.5.0 would have a serious bug which makes e.g. on all Debian systems all KDE apps crash on startup, and let's say 4.5.1 would fix this problem. Wouldn't it make sense to require version 4.5.1 in that case ? At least that's what I do for cmake.
In the new features of CMake 2.6.0 there were a few problems, which all together were serious enough for requiring 2.6.2 (an issue handling RPATH -> apps may get the wrong library using startup, i.e. not start or not work correctly, an issue with finding config files on 64-bit machines -> build broken, not handling the debug and optimized keywords when setting the LINK_INTERFACE_LIBRARIES property -> build broken).
If we would have stayed with 2.6.0, there would have been problem reports about these issues (and/or ugly hacks in the cmake scripts). The only thing I would have been able to tell those people would have been "install 2.6.2". So, that's what I did right now, automatically, in advance. Will save me so much time I can spend on other things which need work (maintaining the buildsystem is more like a support job than a development job).
If we would have stayed with 2.6.0 for KDE 4.2 (remember that until now all released versions of KDE4 require 2.4.5), there would have been two options: stay with 2.6.0 and the known problems also for KDE 4.3 (not good, having to deal with the same actually fixed problems until summer next year), or requiring 2.6.0 for 4.2 and 2.6.2 for 4.3. Which also wouldn't be good, then each version of KDE would require another version of cmake. That would have been much worse than increasing the required version during one development cycle twice. To all users and 3rd party developers this is only once.
And to make this upgrade easier although there are not yet packages for all distros, I provided here a small scripts how it can be done manually in a very clean way with minimal work.
Alex
Re: Release knowingly non-working software ?
I actually agree with your rationale to require cmake 2.6.2, but one sentence in your post strikes me as very wrong:
> So, let's say Qt 4.5.0 would have a serious bug which makes e.g. on all Debian systems
> all KDE apps crash on startup, and let's say 4.5.1 would fix this problem. Wouldn't it
> make sense to require version 4.5.1 in that case ?
No, in this case, it wouldn't make sense to require 4.5.1 on anything other than Debian. I'd very much like to avoid a repeat of the GCC 4.0.0 blacklist fiasco. For those not in the know, the GCC 4.0.0 which shipped with Fedora Core 4 was actually a build between 4.0.0 and 4.0.1 (it was not possible to just ship 4.0.1 as it wasn't released in time) which had the offending bugs (the wrong-code bugs KDE blacklisted GCC 4.0.0 for) already fixed. But it still reported itself as 4.0.0, with the result that Fedora had to patch every single KDE package with a patch like this until GCC was updated to a point release a few months after the FC4 release (luckily Fedora does upgrades like that or we would have been stuck with the unblacklisting hacks for the entire life of FC4).
So blacklisting a version globally for a distro-specific issue strikes me as very wrong. I'd say it is a badly-chosen example. Even blacklisting per version can be wrong (as the GCC 4.0.0 example shows), but I'm not sure how to handle this better. In the cmake case, I think just requiring 2.6.2 is the right thing to do.
6 easy steps to compile cmake
6 easy steps to compile cmake for Debian Lenny (and Debian derivatives)
1. Add
to your
2. sudo apt-get update
3. sudo apt-get build-dep cmake
4. apt-get source cmake
5. cd cmake-2.6.2/
6. sudo dpkg-buildpackage
Then you'll have cmake binary packages in your working directory
Fedora 9
Or for Fedora 9 users, just run "yum upgrade". :-)
https://admin.fedoraproject.org/updates/F9/FEDORA-2008-9347
And of course Fedora 10 will ship with 2.6.2.