On quarta-feira, 31 de outubro de 2012 08.02.20, Thiago Macieira wrote: > On quarta-feira, 31 de outubro de 2012 12.23.27, Oswald Buddenhagen wrote: > > > 3) library versioning (i.e., adding "5" to the library name) > > > > > > > > -1 > > > > > > > > renaming is unnecessary: > > - there is no problem at all at run-time > > - the problem at build time is solved by -L flags. there is no need for > > > > an unversioned symlink in /usr/lib. > > > > renaming is a bit disruptive: > > - projects not done with qmake need adjustment/ifdefs > > > > - but then, they probably need adjustment anyway due to the libraries > > having been split, etc. > > Ossi: let me ask you something then: do you want our make install to manage > both /usr/lib and /usr/lib/qt5/lib? > > If so, we need to know about both build dirs and therefore we need -- > prefix=/usr on installations. > > If not, I am going to require you to write a script for distros installing > each Qt tarball so that they do the right thing for each library and it > does not hardcode anything. > > My argument is that the split is necessary because we're being asked to > manage all of this. I'm also with Ján here that trying to override the > default search paths is troublesome. Some less sophisticated buildsystems > might add - L/usr/lib64 due to other dependencies saying that is necessary, > then all of a sudden the application will start linking to Qt 4. > > (on OpenSUSE) $ mysql_config --libs > -L/usr/lib64 -lmysqlclient -lpthread -lz -lm -lrt -lssl -lcrypto -ldl > > Mark my words: this is a recipe for disaster.
Here's another reason why we need to manage our libraries properly: cmake and
pkg-config files.
With the library renaming proposed above, distributions can set --
libdir=/usr/lib, /usr/lib64, /usr/lib/x86-64-gnu-linux/, etc. That will
install the *.so files in LIBDIR, where they could conflict with the Qt 4 files
if they aren't renamed.
Setting LIBDIR to /usr/lib/qt5/lib (or equivalent) means the CMake and pkg-
config files get installed to /usr/lib/qt5/lib/{cmake,pkgconfig}, which is not a
path that those systems search by default. That means users of those systems
need to know where Qt 5 is installed in the first place. That defeats the
purpose of having those files in the first place, which is to tell those 3rd-
party build systems how to find Qt.
If we don't rename the libraries, we need to add more options to configure:
cmakedir, pkgconfigdir and who knows what else in the future.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
