Upgrade to Qt 4.5

[Alejandro Exojo]

El Viernes, 13 de Marzo de 2009, Matthew Woehlke escribió:
> Alejandro Exojo wrote:
> > And do you recompile everything in your system each time you upgrade GCC
>
> If you run gentoo, you *should* recompile after a major gcc upgrade (on
> the theory that you'll get better, faster code by doing so) :-).
>
> > or  libc?
>
> Again, on gentoo I would consider it :-). And I bet you'd be surprised
> the extent to which most distros usually have software built against the
> latest glibc.

I was considering distributions which ship binary packages. I don't know how 
Gentoo works, but I supposed that it works in a similar way to compiling from 
source without all the automation provided by the distribution tools.

> Another reason I rebuild is it's a good excuse to nuke the install tree
> and make sure there's no cruft floating around. That's usually not an
> issue when you're dealing with distro packages, but it *is* (or at
> least, can be) when you're overwriting an install on a regular basis
> with no clean-up happening in between. And while CMake is far better
> than most build systems about always rebuilding anything that needs to
> rebuild, like any software there is a possibility of bugs, both in CMake
> and in KDE's build system.

Yes, and, last time I checked, cmake had no "make uninstall", so it's possible 
that some renamed files are still kept in the installation directory. But I 
think that this cleanup, or fresh start, etc., can be done without 
correlation with a new Qt version. I mean, maybe you still have the now 
obsolete "plasma" binary, which is been renamed to "plasma-desktop", but this 
cruft left doesn't have to do with a new Qt version. :)

> Also, there is a very good reason why you *should* rebuild; to take
> advantage of new features, and to allow compatibility code to die. I
> know KDE picks up the occasional #ifdef based on Qt version. In some
> cases, rebuilding will improve things, enable new features, etc. In some
> (less common) cases, things may be *genuinely broken* if the 4.4 code is
> used with 4.5.

I can think of the workarounds that Plasma developers had to do with graphics 
view and the differences between 4.4 and 4.5, true, but I think that this are 
the exception, not the rule.

> Finally, all the header changes mean that the next "incremental" build
> will likely be nothing of the sort, regardless, so there's something to
> be said for "getting it over with". (On an unrelated note, I feel sorry
> for the non-native-en_US people that will be trying to parse that
> expression; I was born en_US and *I'm* having trouble :-).)

> All that said... there's an excellent chance that nothing bad will
> happen if you don't rebuild. I just don't think you should be insulting
> people that *do* run full rebuilds on major Qt updates. (Or else, you
> should choose your words more carefully so you don't seem to be doing so
> ;-).)

Sorry if someone felt insulted by my words. I tried to be clear and firm in my 
position, but not attacking at all. And that's why I said that if somebody 
didn't knew it was OK. I just wanted that people used rationality and common 
sense: if a rebuild was _needed_ (and that's the word David used and that 
made me feel forced to reply), unstable/development binary distribution 
branches could not exist the way they do (I mean branches like Sid, Rawhide, 
Cooker, etc.). Each time a new minor version of a library is uploaded, all 
packages depending on it are not recompiled (at least not in Debian), and 
certainly binary only packages just _can't_ be recompiled.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.