Re: [Development] Pending decisions on co-installation
On sexta-feira, 2 de novembro de 2012 15.11.40, Oswald Buddenhagen wrote: > > But we're not installing to the common directory. We're installing to an > > arch- specific path, which the existing infrastructure may not be > > equipped to handle. So it's entirely possible we'll end up with > > duplication of executables.> > > > > no, we don't, because nobody would install both linugist:i386 and > linguist:amd64. this follows directly from what i said before. Assuming the distribution splits linguist from the arch-specific tooling like lupdate. Otherwise you'll have the duplication. In any case, I've been investigating how to make multiarch work and there's surprisingly little information for tooling and building. My conclusion so far is that we don't have to worry about the 64-bit wrapper finding the 32-bit tools. The distributions will need to get their act together first before we can fix this. -- 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
Re: [Development] Pending decisions on co-installation
On Thu, Nov 01, 2012 at 01:12:14PM -0700, Thiago Macieira wrote:
> On quinta-feira, 1 de novembro de 2012 20.32.06, Oswald Buddenhagen wrote:
> > > You're asking that they have a different 32-bit package to be installed on
> > > 64- bit systems than then 32-bit package to be installed on 32-bit
> > > systems. That's a policy change.
> >
> > last time i looked, /usr/lib/i386-linux-gnu was already different from
> > /usr/lib/x86_64-linux-gnu, so "policy change" seems a bit far-fetched.
>
> I'm sorry, let me be more precise:
>
> /usr/bin is the same for both installations. The distributions have already
> figured out a way of de-duplicating the binaries, if they end up in the
> common
> directory. I'm not sure exactly *how* it works or even if it works the same
> way for all distros, but they have clearly figured it out.
>
apparently
> But we're not installing to the common directory. We're installing to an arch-
> specific path, which the existing infrastructure may not be equipped to
> handle.
> So it's entirely possible we'll end up with duplication of executables.
>
no, we don't, because nobody would install both linugist:i386 and
linguist:amd64. this follows directly from what i said before.
> > the question is only whether we go the whole nine yards or stop halfway
> > through. if we stop, the configure command line will be -prefix /usr
> > -bindir /usr/lib/$arch/qt5/bin, which isn't exactly the pinnacle of
> > beauty. but then, -archlibdir needs adjustment anyway.
>
> Are these the three possibilities you're thinking of?
>
>
>
> a-bis) archdatadir exists, but its default is inadequate
> configure -prefix /usr -bindir %{_libdir}/qt5/bin -datadir
> %{_datadir}/qt5 \
> -archdatadir %{_libdir}/qt5 -nomake examples -nomake tests
> [same as a-original]
>
> a-ter) archdatadir exists and its default is adequate, but we still don't
> manage symlinks:
> configure -prefix /usr -bindir %{_libdir}/qt5/bin \
> -nomake examples -nomake tests
> [same as a-orginal]
>
>
>
> b) we do manage /usr/bin, but archdatadir and datadir defaults are inadequate:
> configure -prefix /usr -datadir %{_datadir}/qt5 -archdatadir \
> %{_libdir}/qt5 -nomake examples -nomake tests
> make
> make install
>
> c) we do manage /usr/bin and the defaults are adequate:
> configure -prefix /usr -nomake examples -nomake tests
> make
> make install
>
> I do realise that the current order of the patches leads to options a and c
> only. I need to split the patch that adds archdatadir so that option b is
> opened up and we can apply the Qml2ImportsPath patch.
>
>
>
> We have then four options due to having two decisions: the defaults
> for archdatadir and datadir, and the managing of symlinks or not.
>
i want the one which is implied by defaults which do not change how
"normal" builds of qt look - that would be a-bis.
the management of symlinks is completely orthogonal to the qt
installation - these are symlinks to the wrapper, and must be part of
its installation process. anything else is fundamentally wrong due to
the 1:n relationship between the wrapper and the qt installations. if
anything at all, the qt installation could try to automatically register
its bindir with an already installed wrapper (but most probably this
should be a separate target, as the registration can touch files outside
-prefix by design).
regards
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Pending decisions on co-installation
On quinta-feira, 1 de novembro de 2012 13.12.14, Thiago Macieira wrote:
> > the question is only whether we go the whole nine yards or stop halfway
> > through. if we stop, the configure command line will be -prefix /usr
> > -bindir /usr/lib/$arch/qt5/bin, which isn't exactly the pinnacle of
> > beauty. but then, -archlibdir needs adjustment anyway.
>
> Are these the three possibilities you're thinking of?
>
> a) we don't do the symlinks in /usr/bin:
> configure -prefix %{_libdir}/qt5 -libdir %{_libdir} -docdir
> %{_docdir} \ -translationsdir %{_datadir}/qt5/translations \
> -nomake examples -nomake tests
> make
> make install
> cd %{_libdir}/qt5/bin
> for f in *; do
> test "$f" = "toolwrapper" && continue
> ln -s %{_libdir}/qt5/bin/toolwrapper %{_bindir}
> done
>
> b) we do manage /usr/bin, but archdatadir and datadir defaults are
> inadequate: configure -prefix /usr -datadir %{_datadir}/qt5 -archdatadir \
> %{_libdir}/qt5 -nomake examples -nomake tests
> make
> make install
>
> c) we do manage /usr/bin and the defaults are adequate:
> configure -prefix /usr -nomake examples -nomake tests
> make
> make install
>
> I do realise that the current order of the patches leads to options a and c
> only. I need to split the patch that adds archdatadir so that option b is
> opened up and we can apply the Qml2ImportsPath patch.
I see a fourth option too, which is a variant of a:
a-bis) archdatadir exists, but its default is inadequate
configure -prefix /usr -bindir %{_libdir}/qt5/bin -datadir
%{_datadir}/qt5
\
-archdatadir %{_libdir}/qt5 -nomake examples -nomake tests
[same as a-original]
a-ter) archdatadir exists and its default is adequate, but we still don't
manage symlinks:
configure -prefix /usr -bindir %{_libdir}/qt5/bin \
-nomake examples -nomake tests
[same as a-orginal]
Considering you've agreed to adding archdatadir, let's discard the a-original
option. We have then four options due to having two decisions: the defaults
for archdatadir and datadir, and the managing of symlinks or not.
--
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
Re: [Development] Pending decisions on co-installation
On quinta-feira, 1 de novembro de 2012 20.32.06, Oswald Buddenhagen wrote:
> > You're asking that they have a different 32-bit package to be installed on
> > 64- bit systems than then 32-bit package to be installed on 32-bit
> > systems. That's a policy change.
>
> last time i looked, /usr/lib/i386-linux-gnu was already different from
> /usr/lib/x86_64-linux-gnu, so "policy change" seems a bit far-fetched.
I'm sorry, let me be more precise:
/usr/bin is the same for both installations. The distributions have already
figured out a way of de-duplicating the binaries, if they end up in the common
directory. I'm not sure exactly *how* it works or even if it works the same
way for all distros, but they have clearly figured it out.
But we're not installing to the common directory. We're installing to an arch-
specific path, which the existing infrastructure may not be equipped to handle.
So it's entirely possible we'll end up with duplication of executables.
Still, according to your suggestion -- wrap all tools -- we'll need that
because the wrapper cannot know which tools have arch-independent uses and
which ones are arch-dependent. That's a decision that the tool can't make and
we'll ask downstream not to make either. Only the Qt Project can make that
decision and -- according to your suggestion -- we will not make.
> > And I'm requesting that we stop this game of "qt sandbox root" and just do
> > it right, like every single other package: --prefix=/usr and manage our
> > stuff properly.
>
> this doesn't quite fit the idea of the executable dispatcher. ;)
Sure it does. Did you see my email that contained the listing of the installed
build? I guess you missed the attachment:
./bin/
./bin/assistant
./bin/designer
./bin/lconvert -> /home/thiago/qt5/lib64/qt5/bin/toolwrapper
./bin/linguist
./bin/lrelease -> /home/thiago/qt5/lib64/qt5/bin/toolwrapper
./bin/lupdate -> /home/thiago/qt5/lib64/qt5/bin/toolwrapper
./bin/pixeltool
./bin/qdbus
./bin/qdbusviewer
./bin/qglinfo
./bin/qmake -> /home/thiago/qt5/lib64/qt5/bin/toolwrapper
./bin/xmlpatterns
./bin/xmlpatternsvalidator
> the question is only whether we go the whole nine yards or stop halfway
> through. if we stop, the configure command line will be -prefix /usr
> -bindir /usr/lib/$arch/qt5/bin, which isn't exactly the pinnacle of
> beauty. but then, -archlibdir needs adjustment anyway.
Are these the three possibilities you're thinking of?
a) we don't do the symlinks in /usr/bin:
configure -prefix %{_libdir}/qt5 -libdir %{_libdir} -docdir %{_docdir} \
-translationsdir %{_datadir}/qt5/translations \
-nomake examples -nomake tests
make
make install
cd %{_libdir}/qt5/bin
for f in *; do
test "$f" = "toolwrapper" && continue
ln -s %{_libdir}/qt5/bin/toolwrapper %{_bindir}
done
b) we do manage /usr/bin, but archdatadir and datadir defaults are inadequate:
configure -prefix /usr -datadir %{_datadir}/qt5 -archdatadir \
%{_libdir}/qt5 -nomake examples -nomake tests
make
make install
c) we do manage /usr/bin and the defaults are adequate:
configure -prefix /usr -nomake examples -nomake tests
make
make install
I do realise that the current order of the patches leads to options a and c
only. I need to split the patch that adds archdatadir so that option b is
opened up and we can apply the Qml2ImportsPath patch.
--
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
Re: [Development] Pending decisions on co-installation
On Thu, Nov 01, 2012 at 09:37:22AM -0700, Thiago Macieira wrote: > On quinta-feira, 1 de novembro de 2012 17.13.58, Oswald Buddenhagen wrote: > > > > > distributions should have *both*: > > > > > /usr/lib/qt5//bin/assistant AND > > > > > /usr/lib64/qt5/bin/assistant > > > > > /usr/lib/qt5//bin/linguist AND > > > > > /usr/lib64/qt5/bin/linguist > > > > > /usr/lib/qt5//bin/designer AND > > > > > /usr/lib64/qt5/bin/designer > > > > > > > > yes. as these applications typically live in separate packages anyway, > > > > there needn't to be an actual duplication if the alternatives are > > > > intelligently managed. for example, your wrapper could support a > > > > secondary source for executables, so if no lib32 version is found, the > > > > lib64 version is automatically used. > > > > > > Right, so not only are you not providing instructions, you're also asking > > > distributions to come up with new packaging rules for multiarch, requiring > > > features in their buildsystems that they don't have yet? > > > > one has to wonder how you arrive at these conclusions ... > > You're asking that they have a different 32-bit package to be installed on 64- > bit systems than then 32-bit package to be installed on 32-bit systems. > That's > a policy change. > last time i looked, /usr/lib/i386-linux-gnu was already different from /usr/lib/x86_64-linux-gnu, so "policy change" seems a bit far-fetched. > > > > On Wed, Oct 31, 2012 at 12:38:06PM -0700, Thiago Macieira wrote: > > > > > I disagree with leaving /usr/bin unmanaged at all. I want to hear the > > > > > arguments on why we should not manage that on "make install". > > > > > > > > because it's outside of -prefix? > > > > > > Clearly we should not touch anything outside -prefix. > > > > > > Which is why I'm proposing we recommend -prefix=/usr and then we *do* > > > manage that. > > > > this is a semantics game. the real prefix (the qt "sandbox" root) will be > > different anyway. just accept that the prefix of the wrapper is a > > different one, and consequently that it is a separate package. > > this wouldn't even change if the packagers use configure's path options > > in such ways that the "prefixes" actually end up intermingled. > > And I'm requesting that we stop this game of "qt sandbox root" and just do it > right, like every single other package: --prefix=/usr and manage our stuff > properly. > this doesn't quite fit the idea of the executable dispatcher. ;) the question is only whether we go the whole nine yards or stop halfway through. if we stop, the configure command line will be -prefix /usr -bindir /usr/lib/$arch/qt5/bin, which isn't exactly the pinnacle of beauty. but then, -archlibdir needs adjustment anyway. > > > Do you hear yourself when you say that our make install is > > > insufficient? That distros need to move files around and create > > > symlinks on their own > > > > this sounds entirely reasonable to me. this is what packaging is about. > > Please talk to packagers then. "Reasonable" is "make install is sufficient". > yes. i've also seen packagers stop packaging KDE because we modularized the repositories. while i can understand a delay due to instantaneous workload, it is completely ridiculous to require upstreams to please the downstreams "just because". if you don't like a job, quit it. anyway, as the library renaming is apparently a decided thing, there is little point in hashing out the stupid arguments, given that this would merely produce an even equation which still calls for a decision. i just don't think you'll get as much out of this (as a whole) as you are hoping for. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Pending decisions on co-installation
On quinta-feira, 1 de novembro de 2012 17.13.58, Oswald Buddenhagen wrote: > > You MUST provide a set of installation instructions. This is YOUR > > proposal, > > which we must analyse and compare to mine. > > my proposal is very simple: wrap everything in QT_HOST_BINS (which > equals QT_INSTALL_BINS on desktops, but it matters for x-builds). Ok, the proposal is that every single binary in BINDIR should be wrapped. At least that's an easy script to write. > > > > distributions should have *both*: > > > > /usr/lib/qt5//bin/assistant AND > > > > /usr/lib64/qt5/bin/assistant > > > > /usr/lib/qt5//bin/linguist AND > > > > /usr/lib64/qt5/bin/linguist > > > > /usr/lib/qt5//bin/designer AND > > > > /usr/lib64/qt5/bin/designer > > > > > > yes. as these applications typically live in separate packages anyway, > > > there needn't to be an actual duplication if the alternatives are > > > intelligently managed. for example, your wrapper could support a > > > secondary source for executables, so if no lib32 version is found, the > > > lib64 version is automatically used. > > > > Right, so not only are you not providing instructions, you're also asking > > distributions to come up with new packaging rules for multiarch, requiring > > features in their buildsystems that they don't have yet? > > one has to wonder how you arrive at these conclusions ... You're asking that they have a different 32-bit package to be installed on 64- bit systems than then 32-bit package to be installed on 32-bit systems. That's a policy change. > > > On Wed, Oct 31, 2012 at 12:38:06PM -0700, Thiago Macieira wrote: > > > > I disagree with leaving /usr/bin unmanaged at all. I want to hear the > > > > arguments on why we should not manage that on "make install". > > > > > > because it's outside of -prefix? > > > > Clearly we should not touch anything outside -prefix. > > > > Which is why I'm proposing we recommend -prefix=/usr and then we *do* > > manage that. > > this is a semantics game. the real prefix (the qt "sandbox" root) will be > different anyway. just accept that the prefix of the wrapper is a > different one, and consequently that it is a separate package. > this wouldn't even change if the packagers use configure's path options > in such ways that the "prefixes" actually end up intermingled. And I'm requesting that we stop this game of "qt sandbox root" and just do it right, like every single other package: --prefix=/usr and manage our stuff properly. > > > On Wed, Oct 31, 2012 at 12:44:53PM -0700, Thiago Macieira wrote: > > > > Here's another reason why we need to manage our libraries properly: > > > > cmake and pkg-config files. [...] > > > > > > as i said probably a week ago already, the locations of the > > > pkg-config/cmake files can be determined by the distros freely - they > > > can just have rpm & co. move them out of -prefix at packaging time. the > > > one thing we need to do is ensuring a consistent naming of the files. > > > provided we want users to be able to use the files without setting up > > > environment variables, we'd need to make them co-installable, indeed. > > > but i'm not entirely conviced we need that: we could just say that > > > pkg-config needs to be set up with the qmake -query output. that might > > > be considered an undue complication, though. > > > > *sigh* > > > > Requiring qmake in order to run cmake or pkg-config is NOT acceptable. > > i don't buy such a statement without justification. This point is now moot. Since Lars decided on having the 5 in the lib names, we can have LIBDIR=/usr/lib and therefore the pkgconfig and cmake files are installed to the proper places. No need for further changes on our side. > > Do you hear yourself when you say that our make install is > > insufficient? That distros need to move files around and create > > symlinks on their own > > this sounds entirely reasonable to me. this is what packaging is about. Please talk to packagers then. "Reasonable" is "make install is sufficient". > actually, because we refuse to tailor it to their needs at the cost of > others. Cost of others? No one else is suffering from this. If there are people who are seeing negative effects from the proposed changes, please tell me, because I still don't see them. Please bring those arguments to the meeting in Berlin. -- 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
Re: [Development] Pending decisions on co-installation
On quinta-feira, 1 de novembro de 2012 08.47.12, Knoll Lars wrote: > > 4) new installation paths (besides the bin directory) > > The latest patch I've provided creates a grouping of all arch-dependent > > files in ARCHDATADIR, with arch-independent files in DATADIR. That > > change, by itself, is innocuous since it doesn't produce any difference > > in installation.> > > > > > > The decision we need is on the defaults for those two directories. My > > proposal is to have ARCHDATADIR=LIBDIR/qt5 and DATADIR=PREFIX/share/qt5 > > on Unix build that require make install *only*. Again, there are > > arguments for and against, so let's hear them. > > Hmm… as far as I can see from the discussion, you only plan on using this > for mkspecs. Is it then worth it? Also, mkspecs have the default/ symlink > which is IMO not arch independent. I think you misunderstood me here. I meant that mkspecs moves from "datadir" to "archdatadir" because I'm splitting the arch-dependent files from the arch-independent ones. Code that tries to find the mkspecs will need to use QLibraryInfo::ArchDataPath or qmake -query QT_INSTALL_ARCHDATA, instead of what they do today. And I'm arguing that it is acceptable because the mkspecs are really no longer compatible with Qt 4, so any code that tried to parse them will need to be updated considerably. I don't expect anyone to be doing this, except for our own tools (qmake, lupdate, lrelease, Creator). However, the actual installation paths will probably not change: /usr/lib/qt5/mkspecs for installed builds, QTDIR/mkspecs elsewhere. There are two proposals here to be decided upon: a) the DATADIR and ARCHDATADIR split, which causes the source-incompatible change for the mkspec parsing. b) the default values for those two: I'm proposing ARCHDATADIR=LIBDIR/qt5 and DATADIR=PREFIX/share/qt5 for installed builds only, ARCHDATADIR = DATADIR PREFIX elsewhere. I really, really, really want A, but I don't really mind either way for B. -- 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
Re: [Development] Pending decisions on co-installation
On Thu, Nov 01, 2012 at 08:20:02AM -0700, Thiago Macieira wrote: > On quinta-feira, 1 de novembro de 2012 10.57.59, Oswald Buddenhagen wrote: > > as pointed out in another mail, this doesn't phaze us a bit - unless > > some distro thinks it's wise to override our choice and install an > > unversioned symlink to /usr/lib64. for which they deserve being lynched > > by their users, so it's not our problem. > > Which they do: the Qt 4 .so files are in /usr/lib64, /usr/lib. Since > mainstream > distros do that, it becomes our problem. > > Do you have a suggestion for fixing this? Please be reasonable -- asking them > to change their policies is not. > they have to adapt to our strict sandboxing requirement for the binaries anyway. it's not unreasonable to expect them to make some minor adjustments to the -dev package, too. > > > If you choose option d, then please provide the script or at least > > > very detailed instructions for distributions on how to populate > > > /usr/bin. > > > > this is part of the installation (instructions) of your (to be > > stand-alone ;) wrapper. > > Ok, so the suggestion from you is that the distros install the wrapper > however > they like. They may wrap some tools, all tools, symlink some others, leave > some unreachable in $PATH... > > And this changes from distro to distro. Great. > > You MUST provide a set of installation instructions. This is YOUR proposal, > which we must analyse and compare to mine. > my proposal is very simple: wrap everything in QT_HOST_BINS (which equals QT_INSTALL_BINS on desktops, but it matters for x-builds). > > > Also, do I understand correctly that you're suggesting that multiarch > > > > > > distributions should have *both*: > > > /usr/lib/qt5//bin/assistant AND > > > /usr/lib64/qt5/bin/assistant > > > /usr/lib/qt5//bin/linguist AND > > > /usr/lib64/qt5/bin/linguist > > > /usr/lib/qt5//bin/designer AND > > > /usr/lib64/qt5/bin/designer > > > > yes. as these applications typically live in separate packages anyway, > > there needn't to be an actual duplication if the alternatives are > > intelligently managed. for example, your wrapper could support a > > secondary source for executables, so if no lib32 version is found, the > > lib64 version is automatically used. > > Right, so not only are you not providing instructions, you're also asking > distributions to come up with new packaging rules for multiarch, requiring > features in their buildsystems that they don't have yet? > one has to wonder how you arrive at these conclusions ... > > On Wed, Oct 31, 2012 at 12:38:06PM -0700, Thiago Macieira wrote: > > > I disagree with leaving /usr/bin unmanaged at all. I want to hear the > > > arguments on why we should not manage that on "make install". > > > > because it's outside of -prefix? > > Clearly we should not touch anything outside -prefix. > > Which is why I'm proposing we recommend -prefix=/usr and then we *do* manage > that. > this is a semantics game. the real prefix (the qt "sandbox" root) will be different anyway. just accept that the prefix of the wrapper is a different one, and consequently that it is a separate package. this wouldn't even change if the packagers use configure's path options in such ways that the "prefixes" actually end up intermingled. > > On Wed, Oct 31, 2012 at 12:44:53PM -0700, Thiago Macieira wrote: > > > Here's another reason why we need to manage our libraries properly: > > > cmake and pkg-config files. [...] > > > > as i said probably a week ago already, the locations of the > > pkg-config/cmake files can be determined by the distros freely - they > > can just have rpm & co. move them out of -prefix at packaging time. the > > one thing we need to do is ensuring a consistent naming of the files. > > provided we want users to be able to use the files without setting up > > environment variables, we'd need to make them co-installable, indeed. > > but i'm not entirely conviced we need that: we could just say that > > pkg-config needs to be set up with the qmake -query output. that might > > be considered an undue complication, though. > > *sigh* > > Requiring qmake in order to run cmake or pkg-config is NOT acceptable. > i don't buy such a statement without justification. pkg-config is used within configure scripts anyway, so requiring environment setup based on previous checks is entirely reasonable - heck, we even manage to do that with qmake. for cmake the situation is somewhat different. steve is trying to ship everything which is needed to use the qt modules with qt itself, so there is no external entity which would obtain the correct path by calling qmake. note that this also means that x-build target selection with the wrapper won't work, either. also, the cmake modules are already versioned - so this isn't an all-or-nothing deal. > Do you hear yourself when you say that our make install is > ins
Re: [Development] Pending decisions on co-installation
On quinta-feira, 1 de novembro de 2012 10.57.59, Oswald Buddenhagen wrote: > > Ossi: let me ask you something then: do you want our make install to > > manage > > both /usr/lib *and* /usr/lib/qt5/lib? > > no. > > > 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 > > as pointed out in another mail, this doesn't phaze us a bit - unless > some distro thinks it's wise to override our choice and install an > unversioned symlink to /usr/lib64. for which they deserve being lynched > by their users, so it's not our problem. Which they do: the Qt 4 .so files are in /usr/lib64, /usr/lib. Since mainstream distros do that, it becomes our problem. Do you have a suggestion for fixing this? Please be reasonable -- asking them to change their policies is not. > > > the -archdatadir option as such does not hurt, but it introduces a > > > backwards-incompatibility (projects which don't use it on a system which > > > uses different dirs will fail to find the data). i'd prefer to postpone > > > this to The Next Real Major Version ™. > > > > The only thing that uses DataDir is qmake, to find its mkspecs. Also, > > quite > > clearly QLibraryInfo is about Qt itself. > > yes. this includes qt translations (and qt docs, but that's relevant > only for creator, pretty much). but these live in the old data path, so > it's ok. No, it doesn't include translations because we have QLibraryInfo::TranslationsPath. If anyone is finding translations by DataPath + "/translations", they deserve to get their code broken. The only thing that uses DataPath are the mkspecs. > > All of our executables are installed to /usr/lib$suffix/qt5/bin. What > > else? > > > > d) we do nothing > > this > > > If you choose any option of a to c, we require --prefix=/usr and > > modification to the buildsystem. > > > > If you choose option d, then please provide the script or at least > > very detailed instructions for distributions on how to populate > > /usr/bin. > > this is part of the installation (instructions) of your (to be > stand-alone ;) wrapper. Ok, so the suggestion from you is that the distros install the wrapper however they like. They may wrap some tools, all tools, symlink some others, leave some unreachable in $PATH... And this changes from distro to distro. Great. You MUST provide a set of installation instructions. This is YOUR proposal, which we must analyse and compare to mine. > > Also, do I understand correctly that you're suggesting that multiarch > > > > distributions should have *both*: > > /usr/lib/qt5//bin/assistant AND > > /usr/lib64/qt5/bin/assistant > > /usr/lib/qt5//bin/linguist AND > > /usr/lib64/qt5/bin/linguist > > /usr/lib/qt5//bin/designer AND > > /usr/lib64/qt5/bin/designer > > yes. as these applications typically live in separate packages anyway, > there needn't to be an actual duplication if the alternatives are > intelligently managed. for example, your wrapper could support a > secondary source for executables, so if no lib32 version is found, the > lib64 version is automatically used. Right, so not only are you not providing instructions, you're also asking distributions to come up with new packaging rules for multiarch, requiring features in their buildsystems that they don't have yet? Do you quite realise how unreasonable this sounds? > On Wed, Oct 31, 2012 at 12:38:06PM -0700, Thiago Macieira wrote: > > I disagree with leaving /usr/bin unmanaged at all. I want to hear the > > arguments on why we should not manage that on "make install". > > because it's outside of -prefix? Clearly we should not touch anything outside -prefix. Which is why I'm proposing we recommend -prefix=/usr and then we *do* manage that. > On Wed, Oct 31, 2012 at 12:44:53PM -0700, Thiago Macieira wrote: > > Here's another reason why we need to manage our libraries properly: > > cmake and pkg-config files. [...] > > as i said probably a week ago already, the locations of the > pkg-config/cmake files can be determined by the distros freely - they > can just have rpm & co. move them out of -prefix at packaging time. the > one thing we need to do is ensuring a consistent naming of the files. > provided we want users to be able to use the files without setting up > environment variables, we'd need to make them co-installable, indeed. > but i'm not entirely conviced we need that: we could just say that > pkg-config needs to be set up with the qmake -query output. that might > be considered an undue complication
Re: [Development] Pending decisions on co-installation
On 10/31/12 15:14, Oswald Buddenhagen wrote: > there is no need to make it ignore anything, as -lQtCore would not find > any of the above files. the unversioned symlink would be found by virtue > of adding -L/usr/lib64/qt5/lib to the linker command line, and that > directory (which you get from qmake -query QT_INSTALL_LIBS) containing > said unversioned symlink. this really isn't rocket science ... Sorry for confusion, I haven't looked at the contents of the qt-devel RPM [1]. As you can see, it pushes an unversioned libQtCore.so into /usr/lib, and that's a problem. [1] http://rpm.pbone.net/index.php3/stat/6/idpl/18333806/dir/scientific_linux_6/com/qt-devel-4.6.2-24.el6.x86_64.rpm With kind regards, Jan -- Trojita, a fast e-mail client -- http://trojita.flaska.net/ signature.asc Description: OpenPGP digital signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Pending decisions on co-installation
On Thu, Nov 1, 2012 at 4:47 PM, Knoll Lars wrote: > > On Oct 30, 2012, at 9:47 PM, Thiago Macieira > wrote: > > 2) QML tool names > > Kai raised the point that many of the QML 2 tools work for QML 1 too and > > maybe > > even for Qt 4's QML 1. We need confirmation on that as well as the > > willingness > > to keep them that way for one or two years at least. For the tools that work > > on both QML engines, we can drop the version number from their names. > > I think most things are now settled, the main remaining ones are the > qmlviewer/qmlscene names. As Chris said, they do somewhat different things. > qmlviewer for QML1 actually adds a 'runtime' object into the QML environment > and does some > other magic. qmlscene is just instantiating a QQuickView and then executing > the qml. So I'd go for qml1viewer and qml2scene, but let's hear if > Chris/Martin have any further comments. Hi all, I have not used QML myself, but is it correct to presume that people will not be mixing QML1 and QML2 in any given project? If so, I was wondering if it's acceptable/feasible to create duplicates (or symlinks) of the tools that work with both QML 1 & 2, i.e. have 2 names for the same tool. I'm thinking this could allow users to consistently invoke all tools using the "qml1" or "qml2" names, as appropriate for their project. Also, this would free the QML2 version for development, without worrying about breaking compatibility. Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Pending decisions on co-installation
On Wed, Oct 31, 2012 at 08:02:20AM -0700, 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? > no. > 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 > as pointed out in another mail, this doesn't phaze us a bit - unless some distro thinks it's wise to override our choice and install an unversioned symlink to /usr/lib64. for which they deserve being lynched by their users, so it's not our problem. > > the -archdatadir option as such does not hurt, but it introduces a > > backwards-incompatibility (projects which don't use it on a system which > > uses different dirs will fail to find the data). i'd prefer to postpone > > this to The Next Real Major Version ™. > > The only thing that uses DataDir is qmake, to find its mkspecs. Also, quite > clearly QLibraryInfo is about Qt itself. > yes. this includes qt translations (and qt docs, but that's relevant only for creator, pretty much). but these live in the old data path, so it's ok. > Other libraries and applications have > no business using those paths. Therefore, I argue that: > > 1) they shouldn't store their files there > 2) if they are using to read some Qt files, the only ones affected are the > mkspecs, which require quite an updated parser anyway. > ok, whatever. > > > 5) executable split between end-user applications and indirect tooling > > > [...] > > > > -2 > > > > > This proposal has met with vehement opposition and I'd like to hear why. > > > > as others pointed out, the split is arbitrary, and - given your wrapper > > - just unnecessary. > > Ok, then let's see what your proposal is: > > All of our executables are installed to /usr/lib$suffix/qt5/bin. What else? > > Please choose one of: > a) we wrap all the executables there in /usr/bin > b) we wrap only some of the executables there in /usr/bin (please include a > list of which ones) > c) we wrap some executables in /usr/bin and we symlink others to /usr/bin > (please include a list of which ones on each group) > d) we do nothing > this > If you choose any option of a to c, we require --prefix=/usr and > modification to the buildsystem. > If you choose option d, then please provide the script or at least > very detailed instructions for distributions on how to populate > /usr/bin. > this is part of the installation (instructions) of your (to be stand-alone ;) wrapper. > Also, do I understand correctly that you're suggesting that multiarch > distributions should have *both*: > /usr/lib/qt5//bin/assistant AND > /usr/lib64/qt5/bin/assistant > /usr/lib/qt5//bin/linguist AND > /usr/lib64/qt5/bin/linguist > /usr/lib/qt5//bin/designer AND > /usr/lib64/qt5/bin/designer > yes. as these applications typically live in separate packages anyway, there needn't to be an actual duplication if the alternatives are intelligently managed. for example, your wrapper could support a secondary source for executables, so if no lib32 version is found, the lib64 version is automatically used. On Wed, Oct 31, 2012 at 12:38:06PM -0700, Thiago Macieira wrote: > I disagree with leaving /usr/bin unmanaged at all. I want to hear the > arguments on why we should not manage that on "make install". > because it's outside of -prefix? On Wed, Oct 31, 2012 at 12:44:53PM -0700, Thiago Macieira wrote: > Here's another reason why we need to manage our libraries properly: > cmake and pkg-config files. [...] > as i said probably a week ago already, the locations of the pkg-config/cmake files can be determined by the distros freely - they can just have rpm & co. move them out of -prefix at packaging time. the one thing we need to do is ensuring a consistent naming of the files. provided we want users to be able to use the files without setting up environment variables, we'd need to make them co-installable
Re: [Development] Pending decisions on co-installation
Hi, after reading through the whole thread, here's my comments on the different parts: On Oct 30, 2012, at 9:47 PM, Thiago Macieira wrote: > If I've forgotten anything, please add. > > As far as I can tell, here are the pending decisions, in increasing order of > severity: > > 1) QML environment variables > The variable for import paths has been versioned from QML_IMPORT_PATH to > QML2_IMPORT_PATH. But I have not changed any of the other variables. We need > a > decision from the team familiar with the engines and the meanings of those > variables to know which ones should be versioned too. > > They need to be versioned if having a value set in it applies to one QML > engine but has ill-effects for the other. Let's separate the import paths. As Chris has pointed out, we do not need changes to the other environment variables, as they are purely developer facing and usually there only for debugging purposes. > > 2) QML tool names > Kai raised the point that many of the QML 2 tools work for QML 1 too and > maybe > even for Qt 4's QML 1. We need confirmation on that as well as the > willingness > to keep them that way for one or two years at least. For the tools that work > on both QML engines, we can drop the version number from their names. I think most things are now settled, the main remaining ones are the qmlviewer/qmlscene names. As Chris said, they do somewhat different things. qmlviewer for QML1 actually adds a 'runtime' object into the QML environment and does some other magic. qmlscene is just instantiating a QQuickView and then executing the qml. So I'd go for qml1viewer and qml2scene, but let's hear if Chris/Martin have any further comments. Btw, we had a discussion here in Oslo that it would be great to at some point have a real qml runtime available. Probably simply called 'qml' as well. But let's keep that for a separate mail. > 3) library versioning (i.e., adding "5" to the library name) > I'd like to see a decision here, one way or the other. I've posted my > arguments in favour more than once and I know there are people who disagree. > So let's hear from them why they disagree so we can see if there's a > consensus[*]. I'll similarly post the arguments in favour and I'd appreciate > if other people who agree did the same. After reading through it all, I'd say let's go with adding the '5' in there. It's slightly ugly, but most people will rarely have a need to see or use the library names directly. It shouldn't really make things more difficult for most of our users. People using qmake or cmake will never even notice. That leaves people with hand-written makefiles/vcproj files etc. Here Windows developers will need to adjust anyway, as we already have the major version number encoded in the dll name. On Linux/Unix some adjustments will also be required due to the library splits, so people will need to touch some pieces there anyway. And on Mac with frameworks nothing changes. So this seams reasonable, and allows for more easy co-installation in /usr/lib. As Thiago pointed out, modifying the link path with -L… is not a very stable solution as soon as 3rd party libs come into play. This is simply the safer solution IMO. > 4) new installation paths (besides the bin directory) > The latest patch I've provided creates a grouping of all arch-dependent files > in ARCHDATADIR, with arch-independent files in DATADIR. That change, by > itself, > is innocuous since it doesn't produce any difference in installation. > > The decision we need is on the defaults for those two directories. My > proposal > is to have ARCHDATADIR=LIBDIR/qt5 and DATADIR=PREFIX/share/qt5 on Unix build > that require make install *only*. Again, there are arguments for and against, > so let's hear them. Hmm… as far as I can see from the discussion, you only plan on using this for mkspecs. Is it then worth it? Also, mkspecs have the default/ symlink which is IMO not arch independent. > > 5) executable split between end-user applications and indirect tooling > The most controversial proposal so far is to split the binaries into two > groups: one that gets installed to PREFIX/bin, containing the executables for > applications run directly by the user and which retain backwards > compatibility > of purpose, and one that gets installed to ARCHDATADIR/bin that contains the > tools that users generally do not run directly and which are specific to a > particular build of Qt. Please note that, in the current implementation, like > in #4 above, most people on this list will not see a change, as it applies to > Unix builds that require make install *only*. > > This proposal has met with vehement opposition and I'd like to hear why. > > As a follow-up to this one, if we do split the executables, we need to decide > which ones are applications and which ones are tooling. And among the latter, > which ones need to be wrapped. It seems to be very hard to get any furthe
Re: [Development] Pending decisions on co-installation
On quinta-feira, 1 de novembro de 2012 11.56.25, Lincoln Ramsay wrote: > On 01/11/12 09:41, Thiago Macieira wrote: > > On quinta-feira, 1 de novembro de 2012 09.23.37, Lincoln Ramsay wrote: > >> On 01/11/12 01:02, Thiago Macieira wrote: > >>> Also, do I understand correctly that you're suggesting that multiarch > >>> > >>> distributions should have *both*: > >>> /usr/lib/qt5//bin/assistant AND > >>> /usr/lib64/qt5/bin/assistant > >>> /usr/lib/qt5//bin/linguist AND > >>> /usr/lib64/qt5/bin/linguist > >>> /usr/lib/qt5//bin/designer AND > >>> /usr/lib64/qt5/bin/designer > >> > >> hang on... why shouldn't they have both of those? > >> > >> a 32-bit assistant is different to a 64-bit assistant > > > > How are they different? > > Well for one thing, you can't run the 32-bit one against a 64-bit > install or vice versa. Any plugins they load (including system style > plugins) must be the same bit-ness. Designer used to load plugins for > custom widgets... not sure if it still does. Sure, you can't run against the wrong install. But the presence of the executable assumes that its dependencies are present and properly installed. So that's not an argument. This is how Linguist, Assistant, xmlpatterns, xmlpatternsvalidator, qglinfo, qdbus, and qdbusviewer go. Their purpose is completely independent of the arch. The plugin argument for Designer has been discussed. So far, our conclusion is to punt the problem because QtWidgets is in Done state. We've punted the problem to the plugins themselves: we're requiring that the plugins be updated to Qt 5, along with Designer itself. Designer's output (the .ui file) is arch-independent and even backwards compatible. As QtWidgets and Designer are in Done, we're not expecting any new features. But even if some come along, the precedent set by tools like Microsoft Word and Libre Office is that you simply provide an option in the Save dialog to save as the previous version. Heck, I thought Designer in Qt 4 still had the option to save as a Qt 3 .ui file, for uic3. I can't find it, though. Also note that, unlike uic3, uic does not load plugins, so all the information it needs to generate the .h file is already present in the .ui. Therefore, if the plugins are updated to Qt 5 and they themselves retain their compatibility of purpose, a file saved by Designer/Qt5 will be processed correctly by uic/Qt4. > If you're on a 64-bit distro, you most likely don't want the 32-bit > versions. If you're on a 32-bit distro, you can't use the 64-bit ones. > That's a distro/packaging problem though. The best we could do is to > remove these from the Qt repo and build/packge them separately (like we > do with Creator). Right, that's a packaging problem. But it's a problem that has been solved by distributions when they first came up with multiarch. For example, for Fedora, a file may belong to both arches, but the 64-bit one wins: $ rpm -qf /usr/bin/mysql_config mysql-5.5.28-1.fc17.x86_64 mysql-5.5.28-1.fc17.i686 $ file /usr/bin/mysql_config /usr/bin/mysql_config: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x815aa7c206d463b192ed09b42965796b4f2e4d05, stripped If designer exists in one common path, outside of LIBDIR, the existing multiarch mechanisms kick in and fix the problem of duplication. -- 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
Re: [Development] Pending decisions on co-installation
On quinta-feira, 1 de novembro de 2012 11.39.22, Chris Adams wrote: > You're right. > Ok, all in all, I think having separate import install paths and separate > envvars to define the import path basedir at runtime is the best solution > after all. Thanks. That makes my life easier because there's no need to patch further. The only variable I've renamed so far was QML_PLUGIN_PATH. I'm still waiting for the final decision on the tooling. The current suggestions are: qml1viewer (from qmlviewer) qml2viewer (from qmlscene) qml1plugindump qml2plugindump (from qmlplugindump) All the rest is unchanged. Please note that we *can* have qmlviewer, provided it's the Qt Quick 1. It works in either scenario of tooling: if it's in $PATH, it's via the toolwrapper, in which case you run the Qt 5 version by adding the -qt5 option. -- 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
Re: [Development] Pending decisions on co-installation
On 01/11/12 09:41, Thiago Macieira wrote: > On quinta-feira, 1 de novembro de 2012 09.23.37, Lincoln Ramsay wrote: >> On 01/11/12 01:02, Thiago Macieira wrote: >>> Also, do I understand correctly that you're suggesting that multiarch >>> >>> distributions should have *both*: >>> /usr/lib/qt5//bin/assistant AND >>> /usr/lib64/qt5/bin/assistant >>> /usr/lib/qt5//bin/linguist AND >>> /usr/lib64/qt5/bin/linguist >>> /usr/lib/qt5//bin/designer AND >>> /usr/lib64/qt5/bin/designer >> hang on... why shouldn't they have both of those? >> >> a 32-bit assistant is different to a 64-bit assistant > How are they different? Well for one thing, you can't run the 32-bit one against a 64-bit install or vice versa. Any plugins they load (including system style plugins) must be the same bit-ness. Designer used to load plugins for custom widgets... not sure if it still does. If you're on a 64-bit distro, you most likely don't want the 32-bit versions. If you're on a 32-bit distro, you can't use the 64-bit ones. That's a distro/packaging problem though. The best we could do is to remove these from the Qt repo and build/packge them separately (like we do with Creator). -- Link ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Pending decisions on co-installation
On Thu, Nov 1, 2012 at 10:56 AM, Thiago Macieira wrote: > On quinta-feira, 1 de novembro de 2012 10.01.11, Chris Adams wrote: > > Regarding QML_IMPORT_PATH, I discussed this yesterday and this morning > with > > Martin Jones and Andrew den Exter, and a couple of things deserve > > mentioning: > > 1) through the versioning of imports (ie, the path lookup with > major/minor > > version appended to module name) a client can create a QML1 > > (QDeclarativeExtensionPlugin) module plugin and install it into, say, > > "$QML_IMPORT_PATH/com/examplecompany/examplemodule1/" and then create a > > QML2 (QQmlExtensionPlugin) module plugin and install it into > > "$QML_IMPORT_PATH/com/examplecompany/examplemodule2/", and this will work > > fine. > > > > That is, the QML_IMPORT_PATH need not be different (or set differently) > > between applications using QML1 and QML2, so long as they import the > > modules of the correct version (ie, for the version of QML against which > > their application is written). > > That assumes that there is a different module name or version number, which > isn't always the case. Qt Quick did decide to break source compatibility by > requiring "import QtQuick 2", but the same does not follow for other > imports. > I guess that's true. But I would argue that any 3rd party module developer who _doesn't_ bump the version of their newly updated module when they rewrite it for a new major version of QML is probably doing their customers a major disservice (since the API of every element they provide will most likely have changed dramatically - even if they themselves didn't add or remove any API - unless the types they provide merely extend QObject instead of QDeclarativeItem / QQuickItem). But you are right. The versioning of the module and the versioning of the language are separate, and in the case that they aren't using the QtQuick primitives, for example, the API offered by types provided by a 3rd party module may remain unchanged, and thus the version should remain unchanged also. I withdraw my argument for my previous stance ;-) > > Note that there already was a separate import path for Qt Quick 1 by > appending > "QtQuick1" to the paths found in QML_IMPORT_PATH. And it is used by some > code > that we install ourselves, like Qt.labs.folderlistmodel. > > $ cat imports/Qt/labs/folderlistmodel/qmldir > plugin qmlfolderlistmodelplugin > > $ cat qml/Qt/labs/folderlistmodel/qmldir > module Qt.labs.folderlistmodel > plugin qmlfolderlistmodelplugin > typeinfo plugins.qmltypes > Unfortunately, folderlistmodel was never properly maintained. I don't know if we bumped the version of it correctly, for example, which is why it looks like it hasn't been installed into a folderlistmodel2 directory. I'm not sure what you mean by the "appending QtQuick1 to the paths found in QML_IMPORT_PATH" -- you mean, in our code at plugin loading time in importdatabase or something? I don't remember that code too well, but arbitrarily changing the import path supplied by the user seems like a bad idea (eg, we can't guarantee that the client has the module they want, installed into QML_IMPORT_PATH/qtquick1 instead of just QML_IMPORT_PATH etc). But I've probably misunderstood what you meant here, can you clarify? In any case, given your previous point (that is, that the version of modules needn't be bumped, necessarily, just because the version of QML changed, if their API remains unchanged) I now am forced to agree with your point that the import paths do need to be separate, for this 3rd-party-module-versioning reason. > > > > So, I'm not sure that QML_IMPORT_PATH needs to be versioned, so long as > > QML's imports versioning system works as expected in future versions. > > I'm not sure that we need to have a qt5/imports dir for QML1 plugins and > a > > separate qt5/qml dir for QML2 plugins, since coexisting qq1/qq2 plugins > > worked previously according to versioning, with the same import path. > > No, they didn't. They already had different import paths before I started > doing > anything. All I did was change the paths searched and the environment > variables that supply the paths. > > > A > > problem might occur if you set QML_IMPORT_PATH to point to a qt4 (QML1) > > import path, and then run a qt5 QML1 application - it'll be trying to > load > > QML1 plugins built against qt4, which will fail. > > Indeed, but hopefully the Qt plugin system will simply refuse to load the > plugins, avoiding a crash. The QML plugins *are* Qt plugins, loaded via > QPluginLoader, aren't they? > Yes, we use QPluginLoader to load plugins in qdeclarativeimport.cpp/qqmlimport.cpp. > > This is the same situation with QT_PLUGIN_PATH, which is unversioned. > However, > the plugin magic is incompatible between Qt 4 and 5, so we can keep the > same > environment variable, which contains both sets of plugin paths. Qt 4 will > not > load Qt 5 plugins and Qt 5 will not load Qt 4 plugins. > Right. > > > Anyway, the long and
Re: [Development] Pending decisions on co-installation
On quinta-feira, 1 de novembro de 2012 10.01.11, Chris Adams wrote: > Regarding QML_IMPORT_PATH, I discussed this yesterday and this morning with > Martin Jones and Andrew den Exter, and a couple of things deserve > mentioning: > 1) through the versioning of imports (ie, the path lookup with major/minor > version appended to module name) a client can create a QML1 > (QDeclarativeExtensionPlugin) module plugin and install it into, say, > "$QML_IMPORT_PATH/com/examplecompany/examplemodule1/" and then create a > QML2 (QQmlExtensionPlugin) module plugin and install it into > "$QML_IMPORT_PATH/com/examplecompany/examplemodule2/", and this will work > fine. > > That is, the QML_IMPORT_PATH need not be different (or set differently) > between applications using QML1 and QML2, so long as they import the > modules of the correct version (ie, for the version of QML against which > their application is written). That assumes that there is a different module name or version number, which isn't always the case. Qt Quick did decide to break source compatibility by requiring "import QtQuick 2", but the same does not follow for other imports. Note that there already was a separate import path for Qt Quick 1 by appending "QtQuick1" to the paths found in QML_IMPORT_PATH. And it is used by some code that we install ourselves, like Qt.labs.folderlistmodel. $ cat imports/Qt/labs/folderlistmodel/qmldir plugin qmlfolderlistmodelplugin $ cat qml/Qt/labs/folderlistmodel/qmldir module Qt.labs.folderlistmodel plugin qmlfolderlistmodelplugin typeinfo plugins.qmltypes > So, I'm not sure that QML_IMPORT_PATH needs to be versioned, so long as > QML's imports versioning system works as expected in future versions. > I'm not sure that we need to have a qt5/imports dir for QML1 plugins and a > separate qt5/qml dir for QML2 plugins, since coexisting qq1/qq2 plugins > worked previously according to versioning, with the same import path. No, they didn't. They already had different import paths before I started doing anything. All I did was change the paths searched and the environment variables that supply the paths. > A > problem might occur if you set QML_IMPORT_PATH to point to a qt4 (QML1) > import path, and then run a qt5 QML1 application - it'll be trying to load > QML1 plugins built against qt4, which will fail. Indeed, but hopefully the Qt plugin system will simply refuse to load the plugins, avoiding a crash. The QML plugins *are* Qt plugins, loaded via QPluginLoader, aren't they? This is the same situation with QT_PLUGIN_PATH, which is unversioned. However, the plugin magic is incompatible between Qt 4 and 5, so we can keep the same environment variable, which contains both sets of plugin paths. Qt 4 will not load Qt 5 plugins and Qt 5 will not load Qt 4 plugins. > Anyway, the long and short of it is -- these variables / configure options > are all developer-facing, so to be honest, we don't think it's a huge issue > to change them if we want to, or leave them (and document the differences > if required) if that is simpler or less confusing. All of them except for QML_IMPORT_PATH. That can be expected to be set on a production system, like some other variables that modify Qt's behaviour post- installation: QT_PLUGIN_PATH QT_QPA_PLATFORM_PLUGIN_PATH QT_QPA_PLATFORM QT_MESSAGE_PATTERN For example, my default shell environment has: $ echo $QT_PLUGIN_PATH /home/thiago/obj/qt/qt-4.8- release/plugins:/home/thiago/kde/lib/kde4/plugins:/usr/lib64/qt4/plugins:/home/thiago/.kde/lib/kde4/plugins/:/home/thiago/kde/lib/kde4/plugins/:/usr/lib/kde4/plugins/:/home/thiago/kde/lib/plugins/:/usr/lib64/kde4/plugins -- 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
Re: [Development] Pending decisions on co-installation
Hi, On Wed, Oct 31, 2012 at 8:17 PM, Sune Vuorela wrote: > On 2012-10-30, Thiago Macieira wrote: > > 1) QML environment variables > > The variable for import paths has been versioned from QML_IMPORT_PATH to > > QML2_IMPORT_PATH. But I have not changed any of the other variables. We > need a > > decision from the team familiar with the engines and the meanings of > those > > variables to know which ones should be versioned too. > > > > They need to be versioned if having a value set in it applies to one QML > > engine but has ill-effects for the other. > > isn't 'not versioning this' a recipe for disaster for both end users of > applications and for developers of applications if we don't do something > Only if the meaning of the variable or config option changes in different versions. Most of the ones that I can think of from the top of my head are applicable in the same way to both QML1 and QML2 (for example, QML_COMPILER_STATS, QML_COMPILER_DUMP, QML_IMPORT_TRACE are all just debugging helpers which cause statistics or extra information to be emitted from the engine), however some others deserve closer inspection: Compiler / Bindings / VM / JS: QML_DISABLE_OPTIMIZER: disables v4 in QML2, disables "compiledbindings" in QML1. In the future, with v4vm or similar, this might mean "use v8 instead of v4vm" in QML2... QML_DISABLE_FAST_PROPERTIES: this config option was QML1 only, and determined whether fast JS accessors for QObject properties were installed, I believe. QML_VERBOSE_COMPILER: verbose output from v4 in QML2 when building the IR QML_BINDINGS_TEST: verbose output from v4 in QML2 creating binding assignments QML_REWRITE_DUMP: verbose output from bindings/signal handlers expression rewriter in both QML1 and QML2 QML_BINDINGS_DUMP: verbose output from compiler in QML1 only QML_CHECK_TYPES: check for typename clashes in both QML1 and QML2 QML_DUMP_ERRORS: output any errors which occurred during typeloading in QML2 instead of just appending to engine's warning list Other: QML_DISABLE_DISTANCEFIELD: the distancefield text rendering is new to Qt5, I believe, so this config option was added in QML2. QML_ENABLE_TEXT_IMAGE_CACHE: in QML1 only, although we still do text image caching in some situations in QML2 QML_FBO_OVERLAY: QML2 only, related to shaders QML_XHR_DUMP: QML1 and QML2, for debugging xml http requests QML_VISUAL_TOUCH_DEBUGGING: QML2 only, for debugging touch and mouse events Scene graph related (QML2 only) - I don't really know what these do in detail, although most seem fairly self explanatory: QML_FLASH_MODE QML_TRANSLUCENT_MODE QML_DEBUG_LEAK_BACKTRACE QML_FORCE_THREADED_RENDERER and its amusing twin QML_BAD_GUI_RENDER_LOOP QML_RENDERER_TIMING QML_FIXED_ANIMATION_STEP QMLSCENE_DEVICE and finally the infamous QML_IMPORT_PATH. Regarding QML_IMPORT_PATH, I discussed this yesterday and this morning with Martin Jones and Andrew den Exter, and a couple of things deserve mentioning: 1) through the versioning of imports (ie, the path lookup with major/minor version appended to module name) a client can create a QML1 (QDeclarativeExtensionPlugin) module plugin and install it into, say, "$QML_IMPORT_PATH/com/examplecompany/examplemodule1/" and then create a QML2 (QQmlExtensionPlugin) module plugin and install it into "$QML_IMPORT_PATH/com/examplecompany/examplemodule2/", and this will work fine. That is, the QML_IMPORT_PATH need not be different (or set differently) between applications using QML1 and QML2, so long as they import the modules of the correct version (ie, for the version of QML against which their application is written). So, I'm not sure that QML_IMPORT_PATH needs to be versioned, so long as QML's imports versioning system works as expected in future versions. I'm not sure that we need to have a qt5/imports dir for QML1 plugins and a separate qt5/qml dir for QML2 plugins, since coexisting qq1/qq2 plugins worked previously according to versioning, with the same import path. A problem might occur if you set QML_IMPORT_PATH to point to a qt4 (QML1) import path, and then run a qt5 QML1 application - it'll be trying to load QML1 plugins built against qt4, which will fail. Anyway, the long and short of it is -- these variables / configure options are all developer-facing, so to be honest, we don't think it's a huge issue to change them if we want to, or leave them (and document the differences if required) if that is simpler or less confusing. > > > > > 2) QML tool names > > Kai raised the point that many of the QML 2 tools work for QML 1 too and > maybe > > even for Qt 4's QML 1. We need confirmation on that as well as the > willingness > > to keep them that way for one or two years at least. For the tools that > work > > on both QML engines, we can drop the version number from their names. > > ack. > Again, most of these tools are developer-facing, so renaming them isn't a huge issue, in our opinion. I think it is a bit ugly that you can't tell from the name whether someth
Re: [Development] Pending decisions on co-installation
On quinta-feira, 1 de novembro de 2012 09.23.37, Lincoln Ramsay wrote: > On 01/11/12 01:02, Thiago Macieira wrote: > > Also, do I understand correctly that you're suggesting that multiarch > > > > distributions should have *both*: > > /usr/lib/qt5//bin/assistant AND > > /usr/lib64/qt5/bin/assistant > > /usr/lib/qt5//bin/linguist AND > > /usr/lib64/qt5/bin/linguist > > /usr/lib/qt5//bin/designer AND > > /usr/lib64/qt5/bin/designer > > hang on... why shouldn't they have both of those? > > a 32-bit assistant is different to a 64-bit assistant How are they different? -- 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
Re: [Development] Pending decisions on co-installation
On 01/11/12 01:02, Thiago Macieira wrote: > Also, do I understand correctly that you're suggesting that multiarch > distributions should have *both*: > /usr/lib/qt5//bin/assistant AND > /usr/lib64/qt5/bin/assistant > /usr/lib/qt5//bin/linguist AND > /usr/lib64/qt5/bin/linguist > /usr/lib/qt5//bin/designer AND > /usr/lib64/qt5/bin/designer hang on... why shouldn't they have both of those? a 32-bit assistant is different to a 64-bit assistant If the user wants to install both, they should both be present -- Link ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Pending decisions on co-installation
On quarta-feira, 31 de outubro de 2012 12.23.27, Oswald Buddenhagen wrote: > > 4) new installation paths (besides the bin directory) > > The latest patch I've provided creates a grouping of all arch-dependent > > files in ARCHDATADIR, with arch-independent files in DATADIR. That > > change, by itself, is innocuous since it doesn't produce any difference > > in installation.> > > > > > > The decision we need is on the defaults for those two directories. My > > proposal is to have ARCHDATADIR=LIBDIR/qt5 and DATADIR=PREFIX/share/qt5 > > on Unix build that require make install *only*. Again, there are > > arguments for and against, so let's hear them. > > > > > > -2 > > it's just pointless to change the defaults (because it's trivial for > distros to adjust the paths, and diversity does not hurt in any way), > and it's counterproductive to introduce inconsistency in the defaults > between installed and non-installed builds. I can accept that we shouldn't change the defaults based on whether we're doing make install or not. The reason I wanted them as the default was so that a minimal "configure -- prefix=/usr" would do the right thing, as most other packages do. That means our instructions to packagers are simpler. They need to pass additional - xxxdir options if they *choose* to according to their distro policies, not because our defaults are incorrect. -- 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
Re: [Development] Pending decisions on co-installation
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
Re: [Development] Pending decisions on co-installation
On quarta-feira, 31 de outubro de 2012 20.31.57, André Pönitz wrote: > > And if we define the cut as the ones that have compatibility of > > purpose and output, versus the ones that don't? > > This sounds not overly wrong as it would reduce some possibly > needless duplication and reduction in diskspace. > > On the other hand, I am not really sure it would be worthwhile. > On the machine in front of me I have e.g. /usr/bin/designer-qt4 > (symlinked via /etc/alternatives/designer and /usr/bin/designer) > with 422584 bytes, assistant with 965092 etc. So the total "shared" > set is in the single digit MB range per installed version of Qt > (minus 1). > > Is this really worth the hassle compared to putting everything > into the same sandbox? Yes. If we can do it and do it cleanly, why not? Don't tell me it's difficult. It's done now and it works. Alberto has suggested that we ensure that all executables are in ARCHDATADIR/bin and we manage a few via symlinks or wrapping in PREFIX/bin. I don't like the idea because I don't see the need to have the executables in both bin directories, but that is a solution I could live with. I disagree with leaving /usr/bin unmanaged at all. I want to hear the arguments on why we should not manage that on "make install". -- 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
Re: [Development] Pending decisions on co-installation
On Tue, Oct 30, 2012 at 05:06:33PM -0700, Thiago Macieira wrote: > On terça-feira, 30 de outubro de 2012 23.52.08, André Pönitz > wrote: > > On Tue, Oct 30, 2012 at 01:47:03PM -0700, Thiago Macieira wrote: > > > 5) executable split between end-user applications and indirect > > > tooling The most controversial proposal so far is to split the > > > binaries into two groups: one that gets installed to > > > PREFIX/bin, containing the executables for applications run > > > directly by the user and which retain backwards compatibility > > > of purpose, and one that gets installed to ARCHDATADIR/bin > > > that contains the tools that users generally do not run > > > directly and which are specific to a particular build of Qt. > > > Please note that, in the current implementation, like in #4 > > > above, most people on this list will not see a change, as it > > > applies to Unix builds that require make install *only*. > > > > > > This proposal has met with vehement opposition and I'd like to > > > hear why. > > > > "There is no clear cut between applications directly run by the > > users and those that are generally not run directly. In some > > cases it is clear, in some others it depends on the actual > > user's habits, and no matter where a cut is made for someone it > > will be wrong." > > And if we define the cut as the ones that have compatibility of > purpose and output, versus the ones that don't? This sounds not overly wrong as it would reduce some possibly needless duplication and reduction in diskspace. On the other hand, I am not really sure it would be worthwhile. On the machine in front of me I have e.g. /usr/bin/designer-qt4 (symlinked via /etc/alternatives/designer and /usr/bin/designer) with 422584 bytes, assistant with 965092 etc. So the total "shared" set is in the single digit MB range per installed version of Qt (minus 1). Is this really worth the hassle compared to putting everything into the same sandbox? Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Pending decisions on co-installation
On quarta-feira, 31 de outubro de 2012 09.46.18, Alberto Mardegan wrote: > On 10/31/2012 01:06 AM, Thiago Macieira wrote: > > In any case, what's the problem with making a subjective decision? Clearly > > the applications need to be split in two groups, so why shouldn't the Qt > > Project make its recommendation to the downstreams? > > I would like that all binaries are installed in ARCHDATADIR/bin, so that > they can be all easily accessed with a custom PATH variable or ad-hoc > scripts or aliases. > If, in addition to that, Qt5 manages to install some symlinks or smart > scripts to PREFIX/bin that's even better. :-) The problem with having all binaries in ARCHDATADIR/bin is that some of those binaries are just plain duplication in multiarch, like designer, assistant, qdbus, qdbusviewer, etc. Please see my email in reply to Ossi and provide me with your suggestions on what to do. > Also consider that if you decide for a split of the binaries, you run > the risk that Qt6 will require a different split (some binary which is > reusable between Qt4 and Qt5 might not be compatible with Qt6, or some > Qt4-incompatible binary might work for both Qt5 and Qt6) and this might > complicate the developer story later on. We don't need to make Qt 5 forwards compatible with a non-existent Qt 6. We just need to make Qt 6 backwards compatible with Qt 5. -- 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
Re: [Development] Pending decisions on co-installation
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. > the -archdatadir option as such does not hurt, but it introduces a > backwards-incompatibility (projects which don't use it on a system which > uses different dirs will fail to find the data). i'd prefer to postpone > this to The Next Real Major Version ™. The only thing that uses DataDir is qmake, to find its mkspecs. Also, quite clearly QLibraryInfo is about Qt itself. Other libraries and applications have no business using those paths. Therefore, I argue that: 1) they shouldn't store their files there 2) if they are using to read some Qt files, the only ones affected are the mkspecs, which require quite an updated parser anyway. > > 5) executable split between end-user applications and indirect tooling > > [...] > > -2 > > > This proposal has met with vehement opposition and I'd like to hear why. > > as others pointed out, the split is arbitrary, and - given your wrapper > - just unnecessary. Ok, then let's see what your proposal is: All of our executables are installed to /usr/lib$suffix/qt5/bin. What else? Please choose one of: a) we wrap all the executables there in /usr/bin b) we wrap only some of the executables there in /usr/bin (please include a list of which ones) c) we wrap some executables in /usr/bin and we symlink others to /usr/bin (please include a list of which ones on each group) d) we do nothing If you choose any option of a to c, we require --prefix=/usr and modification to the buildsystem. If you choose option d, then please provide the script or at least very detailed instructions for distributions on how to populate /usr/bin. Also, do I understand correctly that you're suggesting that multiarch distributions should have *both*: /usr/lib/qt5//bin/assistant AND /usr/lib64/qt5/bin/assistant /usr/lib/qt5//bin/linguist AND /usr/lib64/qt5/bin/linguist /usr/lib/qt5//bin/designer AND /usr/lib64/qt5/bin/designer If you're not suggesting that, then are you suggesting that those applications should be symlinked directly to /usr/bin, instead of tool-wrapped (which detects multiarch)? Are there any other tools that you suggest should be symlinked? -- 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
Re: [Development] Pending decisions on co-installation
On Wed, Oct 31, 2012 at 01:26:09PM +0100, Jan Kundrát wrote: > On 10/31/12 12:23, Oswald Buddenhagen wrote: > > 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. > > On RHEL6, this is how it looks right now: > > kundratj@noe2 ~ $ locate /libQtCore.so > /usr/lib64/libQtCore.so.4 > /usr/lib64/libQtCore.so.4.6 > /usr/lib64/libQtCore.so.4.6.2 > > If I remember correctly, it's rather hard to persuade the linker to > ignore stuff below /usr/lib64 and use some other destination instead. > there is no need to make it ignore anything, as -lQtCore would not find any of the above files. the unversioned symlink would be found by virtue of adding -L/usr/lib64/qt5/lib to the linker command line, and that directory (which you get from qmake -query QT_INSTALL_LIBS) containing said unversioned symlink. this really isn't rocket science ... ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Pending decisions on co-installation
On 2012-10-31, Poenitz Andre wrote: > This is not about "overriding someone". This is about ranking the user > experience of the majority of users higher than the convenience of a > handful of Linux distribution packagers - half which will do their own > renaming anyway, no matter what the official solution will look like. I really think that if we (qt project) has to rely on us (packagers) to do and get the renaming right then we (qt project) has failed. And I still think that the majority of our (qt project *and* distribution packagers) use Qt from distribution packages. /Sune ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Pending decisions on co-installation
On 10/31/12 12:23, Oswald Buddenhagen wrote: > 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. On RHEL6, this is how it looks right now: kundratj@noe2 ~ $ locate /libQtCore.so /usr/lib64/libQtCore.so.4 /usr/lib64/libQtCore.so.4.6 /usr/lib64/libQtCore.so.4.6.2 kundratj@noe2 ~ $ rpm -qf /usr/lib64/libQtCore.so.4 qt-4.6.2-24.el6.x86_64 If I remember correctly, it's rather hard to persuade the linker to ignore stuff below /usr/lib64 and use some other destination instead. I tend to purge such unpleasant memories from my mind, though, so I cannot provide much detail. I suspect that RHEL6 would be on the top of the list of Linux distributions to support. > 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. I can imagine that updating a few lines in a project's build system to make it link against a different library name would be the smallest obstacle of any porting process, especially compared to other changes required. Again, I might be wrong. Cheers, Jan -- Trojita, a fast e-mail client -- http://trojita.flaska.net/ signature.asc Description: OpenPGP digital signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Pending decisions on co-installation
this is just re-iterating stuff, but whatever. On Tue, Oct 30, 2012 at 01:47:03PM -0700, Thiago Macieira wrote: > 1) QML environment variables > +1 > 2) QML tool names > 0 > 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. otoh, we probably should rename the .pc files. this does *not* imply renaming the libraries, except that it's less work with qmake, and you already have done it. so not having definite arguments either side, i'd lean to the status quo. but feel free to try making a strong case in favor of change. > 4) new installation paths (besides the bin directory) > The latest patch I've provided creates a grouping of all arch-dependent files > in ARCHDATADIR, with arch-independent files in DATADIR. That change, by > itself, > is innocuous since it doesn't produce any difference in installation. > > The decision we need is on the defaults for those two directories. My > proposal > is to have ARCHDATADIR=LIBDIR/qt5 and DATADIR=PREFIX/share/qt5 on Unix build > that require make install *only*. Again, there are arguments for and against, > so let's hear them. > -2 it's just pointless to change the defaults (because it's trivial for distros to adjust the paths, and diversity does not hurt in any way), and it's counterproductive to introduce inconsistency in the defaults between installed and non-installed builds. the -archdatadir option as such does not hurt, but it introduces a backwards-incompatibility (projects which don't use it on a system which uses different dirs will fail to find the data). i'd prefer to postpone this to The Next Real Major Version ™. > 5) executable split between end-user applications and indirect tooling > [...] > -2 > This proposal has met with vehement opposition and I'd like to hear why. > as others pointed out, the split is arbitrary, and - given your wrapper - just unnecessary. > Finally, I am not listing the separation of paths for QML 1 and 2, since I > have not heard opposition to that fact. If I'm wrong, do speak up. > +2 the relavant patch is delayed only because of the dependency on 4. regards ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Pending decisions on co-installation
On Wednesday, October 31, 2012 09:46:18 Alberto Mardegan wrote: > Also consider that if you decide for a split of the binaries, you run > the risk that Qt6 will require a different split (some binary which is > reusable between Qt4 and Qt5 might not be compatible with Qt6, or some > Qt4-incompatible binary might work for both Qt5 and Qt6) and this might > complicate the developer story later on. I think this is a good point. Any solution which is not guaranteed to work for Qt 6 is probably not a good enough solution. Thanks, -- Stephen Kelly | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ** Qt Developer Conference: http://qtconference.kdab.com/ ** 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
Re: [Development] Pending decisions on co-installation
> -Original Message- > From: development-bounces+kai.koehne=digia@qt-project.org > [mailto:development-bounces+kai.koehne=digia@qt-project.org] On > Behalf Of Thiago Macieira > [...] > 2) QML tool names > Kai raised the point that many of the QML 2 tools work for QML 1 too and > maybe even for Qt 4's QML 1. We need confirmation on that as well as the > willingness to keep them that way for one or two years at least. For the > tools that work on both QML engines, we can drop the version number from > their names. qmlprofiler - works with Qt 4.8 target, Christiaan Janssen as QML Profiler maintainer agrees to further support it. qmlmin - tried it successfully with some Qt 4.8 .qml files. I think this is a safe bet, since we just extended the .qml grammar in QtQuick2. CC'ed Roberto (the original author) anyway. qmlscene - this potentially loads binary Qt plugins, therefore tied to Qt version qmlplugindump - sole purpose is to load binary plugins. Highly tied to Qt version. qmlbundle - New in QtQuick2, but it's unfortunately completely undocumented [1]. Not sure whether it'll break with a QtQuick3. qmltestrunner - New in QtQuick2. Not sure whether it makes sense to promise compatibility with a QtQuick3. So, I think we can move qmlprofiler, qmlmin to user tools (available in default PATH) and keep their names. Regarding the naming, I think only the qmlscene and qmlviewer names really matter - that's the tools people call often, and that's why I think we should keep them also in a default PATH (disambiguating them from qt 4 qmlviewer by name). A quick poll in the office ended up with qml1viewer, qml2viewer as winner :) [1]: Created https://bugreports.qt-project.org/browse/QTBUG-27783 My 2 cents, Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Pending decisions on co-installation
Sune Vuorela:
> This is something that will happen to be done. and for the sake of
> documentation and support, please let it be consistant not only across
> distributions, but also across platforms so that documentations don't
> have to be
> if mac | upstream-provided-linux-builds {
> run qmake
> } else if windows {
> run qmake.exe
> } else if debian {
> run qmake-qt5
> } elese if fedora {
> run qmake5
Nobody was asking for that.
The attempts at a solution were revolving so far around
(a) providing a means to select a sandboxed Qt version
(b) running qmake
(a) can be as much as "nothing" on all setups that only have a single
version of Qt around, or some other means to switch (like when using
Creator, or whatever distributions consider "native" on their system),
and (b) is obviously cross-platform.
> Yes. we need to do something. and if the 'something' is to ask Lars as
> chief maintainer to override Ossi, then we must do that.
This is not about "overriding someone". This is about ranking the user
experience of the majority of users higher than the convenience of a
handful of Linux distribution packagers - half which will do their own
renaming anyway, no matter what the official solution will look like.
Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Pending decisions on co-installation
On 2012-10-30, Thiago Macieira wrote:
> 1) QML environment variables
> The variable for import paths has been versioned from QML_IMPORT_PATH to
> QML2_IMPORT_PATH. But I have not changed any of the other variables. We need
> a
> decision from the team familiar with the engines and the meanings of those
> variables to know which ones should be versioned too.
>
> They need to be versioned if having a value set in it applies to one QML
> engine but has ill-effects for the other.
isn't 'not versioning this' a recipe for disaster for both end users of
applications and for developers of applications if we don't do something
>
> 2) QML tool names
> Kai raised the point that many of the QML 2 tools work for QML 1 too and
> maybe
> even for Qt 4's QML 1. We need confirmation on that as well as the
> willingness
> to keep them that way for one or two years at least. For the tools that work
> on both QML engines, we can drop the version number from their names.
ack.
> 3) library versioning (i.e., adding "5" to the library name)
> I'd like to see a decision here, one way or the other. I've posted my
> arguments in favour more than once and I know there are people who disagree.
> So let's hear from them why they disagree so we can see if there's a
> consensus[*]. I'll similarly post the arguments in favour and I'd appreciate
> if other people who agree did the same.
I would really like to see a '5' added. that way, people can use distro
packages and develop for qt4 on the same installation as they develop
for qt5. And this is very much going to be a issue.
the /usr/lib/libQtCore.so symlink can only point to one place at a time.
Alternatively, distributions will do something like that, and maybe even
do it differently and if we ar ereal lucky even break the much-valued
binary compatibility between installations - assuming that one distro
does libQt5Core, another does libQtCore5 and some just does a libQtCore.
The only way to prevent this is that we as Qt project (as oppsode to we
as packagers) actually does it. Having distro-qt's binary compatible
with upstream qt and other qt's (modulo fuckups) is a advantage.
> 4) new installation paths (besides the bin directory)
> The latest patch I've provided creates a grouping of all arch-dependent files
> in ARCHDATADIR, with arch-independent files in DATADIR. That change, by
> itself,
> is innocuous since it doesn't produce any difference in installation.
>
> The decision we need is on the defaults for those two directories. My
> proposal
> is to have ARCHDATADIR=LIBDIR/qt5 and DATADIR=PREFIX/share/qt5 on Unix build
> that require make install *only*. Again, there are arguments for and against,
> so let's hear them.
For me, ensuring a 100% correct split between arch-dep and arch-indep
files isn't the most important issue, given that we, at a bit of a disk
space cost can put files where we are in doubt
> 5) executable split between end-user applications and indirect tooling
> The most controversial proposal so far is to split the binaries into two
> groups: one that gets installed to PREFIX/bin, containing the executables for
> applications run directly by the user and which retain backwards
> compatibility
> of purpose, and one that gets installed to ARCHDATADIR/bin that contains the
> tools that users generally do not run directly and which are specific to a
> particular build of Qt. Please note that, in the current implementation, like
> in #4 above, most people on this list will not see a change, as it applies to
> Unix builds that require make install *only*.
>
> This proposal has met with vehement opposition and I'd like to hear why.
This is something that will happen to be done. and for the sake of
documentation and support, please let it be consistant not only across
distributions, but also across platforms so that documentations don't
have to be
if mac | upstream-provided-linux-builds {
run qmake
} else if windows {
run qmake.exe
} else if debian {
run qmake-qt5
} elese if fedora {
run qmake5
}
Yes. we need to do something. and if the 'something' is to ask Lars as
chief maintainer to override Ossi, then we must do that.
/Sune
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Pending decisions on co-installation
On 10/31/2012 01:06 AM, Thiago Macieira wrote: > In any case, what's the problem with making a subjective decision? Clearly the > applications need to be split in two groups, so why shouldn't the Qt Project > make its recommendation to the downstreams? I would like that all binaries are installed in ARCHDATADIR/bin, so that they can be all easily accessed with a custom PATH variable or ad-hoc scripts or aliases. If, in addition to that, Qt5 manages to install some symlinks or smart scripts to PREFIX/bin that's even better. :-) Also consider that if you decide for a split of the binaries, you run the risk that Qt6 will require a different split (some binary which is reusable between Qt4 and Qt5 might not be compatible with Qt6, or some Qt4-incompatible binary might work for both Qt5 and Qt6) and this might complicate the developer story later on. If we could say that everything is guaranteed to be in (at least) ARCHDATADIR/bin, that's some sure information we (or distros) can use to build better/custom tools on top of that. Ciao, Alberto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Pending decisions on co-installation
On terça-feira, 30 de outubro de 2012 23.52.08, André Pönitz wrote: > On Tue, Oct 30, 2012 at 01:47:03PM -0700, Thiago Macieira wrote: > > 5) executable split between end-user applications and indirect tooling > > The most controversial proposal so far is to split the binaries into two > > groups: one that gets installed to PREFIX/bin, containing the executables > > for applications run directly by the user and which retain backwards > > compatibility of purpose, and one that gets installed to ARCHDATADIR/bin > > that contains the tools that users generally do not run directly and > > which are specific to a particular build of Qt. Please note that, in the > > current implementation, like in #4 above, most people on this list will > > not see a change, as it applies to Unix builds that require make install > > *only*. > > > > This proposal has met with vehement opposition and I'd like to hear why. > > "There is no clear cut between applications directly run by the users and > those that are generally not run directly. In some cases it is clear, in > some others it depends on the actual user's habits, and no matter where > a cut is made for someone it will be wrong." And if we define the cut as the ones that have compatibility of purpose and output, versus the ones that don't? Assistant is meant to visualise documentation and its input files remain compatible. Designer edits .ui files and its output is compatible, even backwards compatible, or could be made so in the Save dialog (like Word or LibreOffice). However, moc doesn't retain compatibility and its output is not backwards compatible. In any case, what's the problem with making a subjective decision? Clearly the applications need to be split in two groups, so why shouldn't the Qt Project make its recommendation to the downstreams? -- 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
Re: [Development] Pending decisions on co-installation
On Tue, Oct 30, 2012 at 01:47:03PM -0700, Thiago Macieira wrote: > 5) executable split between end-user applications and indirect tooling > The most controversial proposal so far is to split the binaries into two > groups: one that gets installed to PREFIX/bin, containing the executables for > applications run directly by the user and which retain backwards > compatibility > of purpose, and one that gets installed to ARCHDATADIR/bin that contains the > tools that users generally do not run directly and which are specific to a > particular build of Qt. Please note that, in the current implementation, like > in #4 above, most people on this list will not see a change, as it applies to > Unix builds that require make install *only*. > > This proposal has met with vehement opposition and I'd like to hear why. "There is no clear cut between applications directly run by the users and those that are generally not run directly. In some cases it is clear, in some others it depends on the actual user's habits, and no matter where a cut is made for someone it will be wrong." Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
