Darren J Moffat wrote:
>> 1. How are we going to deliver multiple versions of QT? > > Is that actually a problem that needs to be solved ? Do we really need > to have multiple versions of QT installed ? Is this what everyone else > does or do they pick one version per release of their os/distribution ? I believe so, yes. Linux doesn't do this. But then Linux liberally breaks things. The result of this is: any 3rd party Linux application which uses QT, delivers their own private copy of QT: Google Earth, Skype first come to mind. Even KDE. Why do they do this ? Because they can't rely on any sense of stability with the QT provided by the Linux distros. Wouldn't it be nice to provide our consumers of our QT some measure of stability ? > If it is why not /usr/include/qt4/4.4.1/ rather than > /usr/qt4/4.4.1/include ? I can change it. But the idea was to have every version of QT4 in its own directory under /usr/qt4/<major-minor-micro>. > >> 2. If we do not deliver multiple versions of QT, and we overwrite the >> header files in /usr/include every time we uprev, we run the risk of >> breaking API and ABI. > > I hope the ABI doesn't break because the header files changed. It can, and it will, this is C++, and there are templates, virtual tables and inline functions. > That might be the behaviour you actually want - force things being built > to use the newer version but still deliver the older libraries so that > existing binaries still run (just like we have done in the past for > other "gui" libraries like motif). I was thinking of doing that for the process of "obsoleting" a QT version: removing the executables, header files, and ancillary files, and only leaving the libraries around. That makes applications linked against QT still work, but prevents creating new applications against the obsolete version. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman at Sun.COM
