On 24/10/12 4:04 PM, Konstantin Ritt wrote:
> You definitely don't want support multiarch configurations out-of-the-box :)
> Well, yeah, switching with `sudo ln -svf /usr/lib/qt5/libexec/qmake5
> /usr/bin/qmake5` is a way more handy than with `qmake -set-qt 5.0-x86`
> (or even with `qmake -set-qt 5
>>> Solution:
>>>
>>> qmake renamed to qmake5 and lives with the other binaries in /bin
>>> Create /usr/bin/qmake5 as a symlink to /bin/qmake5 for Linux
>>> distro builds - triggered by some set of configure flags, NOT default
>>> behaviour for a source build
>>
>> You definitely don't want support
On 24 Oct 2012, at 08:04, Konstantin Ritt
wrote:
>> Solution:
>>
>> qmake renamed to qmake5 and lives with the other binaries in /bin
>> Create /usr/bin/qmake5 as a symlink to /bin/qmake5 for Linux
>> distro builds - triggered by some set of configure flags, NOT default
>> behaviour for a sour
On 23 Oct 2012, at 19:03, Thiago Macieira
wrote:
> On terça-feira, 23 de outubro de 2012 16.33.05, Ziller Eike wrote:
So that if you happen to have a "real" qmake instead of the wrapper in
the
PATH on linux, you don't realize that when you are doing "qmake -qt5" to
force "mo
> Solution:
>
> qmake renamed to qmake5 and lives with the other binaries in /bin
> Create /usr/bin/qmake5 as a symlink to /bin/qmake5 for Linux
> distro builds - triggered by some set of configure flags, NOT default
> behaviour for a source build
You definitely don't want support multiarch config
On terça-feira, 23 de outubro de 2012 23.12.58, André Pönitz wrote:
> Moreover, it is a reasonable assumption that only few Qt based
> Windows-only projects supporting VS use qmake at all, and that most
> non-trivial cross-platform Qt based projects supporting VS maintain a
> "real" .vcproj in para
On terça-feira, 23 de outubro de 2012 21.40.41, Oswald Buddenhagen wrote:
> > The difference is that xmlpatterns, like qdbus and the other
> > applications, can be updated by the Debian alternatives mechanism.
>
> yes, debian. have you checked that this is true for all relevant
> downstreams?
The
On 24/10/12 04:33, Thiago Macieira wrote:
> I think we are keeping it simple. The current proposal is the simplest
> that still works. If you can come up with something even simpler, I'll
> gladly accept it.
>>> If the option is required in one platform and does not cause anything but
>>> a minor
Thiago Macieira schreef op ma 22-10-2012 om 11:33 [-0700]:
> Question to distros: what's the proper way to solve the "config tool"
> multiarch
> problem? TBH, this looks like an unsolved problem:
>
> $ i386 pkg-config --cflags dbus-1
> -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include
> $
Thiago Macieira schreef op zo 21-10-2012 om 10:51 [-0700]:
> I'm waiting for packagers and
> others to comment on the proposal.
Hi,
I think that having a centralized qmake wrapper is a nice compromise.
The distro package maintainers can then provide a /usr/bin/qmake wrapper
which by default poin
On Mon, Oct 22, 2012 at 01:46:09PM -0700, Thiago Macieira wrote:
> On segunda-feira, 22 de outubro de 2012 21.21.17, André Pönitz wrote:
> > On Mon, Oct 22, 2012 at 09:08:38AM -0700, Thiago Macieira wrote:
> > > On segunda-feira, 22 de outubro de 2012 15.45.56, Oswald
> > >
> > > Buddenhagen wrote
On Tue, Oct 23, 2012 at 10:18:38AM -0700, Thiago Macieira wrote:
> On terça-feira, 23 de outubro de 2012 18.29.34, Oswald Buddenhagen wrote:
> > > We've been over this: because I'd rather do this right and once and for
> > > all. Who are the best people to make sure that all tools continue to work
On terça-feira, 23 de outubro de 2012 10.42.58, BRM wrote:
> > In any case, "-qt5" may not mean "latest", but simply
> > "default 5.x version".
> > The implementation will decide what that means.
>
> How is this any better then updating LSB/FHS with guidelines on how to
> properly install Qt on a U
ent: Tuesday, October 23, 2012 1:03 PM
>> Subject: Re: [Development] New proposal for the tool naming
>>
>> On terça-feira, 23 de outubro de 2012 16.33.05, Ziller Eike wrote:
>>> >> So that if you happen to have a "real" qmake instead of
>> the
> From: Thiago Macieira
> Sent: Tuesday, October 23, 2012 1:03 PM
> Subject: Re: [Development] New proposal for the tool naming
>
> On terça-feira, 23 de outubro de 2012 16.33.05, Ziller Eike wrote:
>> >> So that if you happen to have a "real" qmake in
On terça-feira, 23 de outubro de 2012 18.29.34, Oswald Buddenhagen wrote:
> > We've been over this: because I'd rather do this right and once and for
> > all. Who are the best people to make sure that all tools continue to work
> > under those conditions? Upstream is.
>
> the thing is that this is
On terça-feira, 23 de outubro de 2012 16.33.05, Ziller Eike wrote:
> >> So that if you happen to have a "real" qmake instead of the wrapper in
> >> the
> >> PATH on linux, you don't realize that when you are doing "qmake -qt5" to
> >> force "most current qt5 version" (or whatever the semantics woul
On 22 Oct 2012, at 17:11, Thiago Macieira wrote:
> On segunda-feira, 22 de outubro de 2012 14.59.09, Ziller Eike wrote:
Just as a side note, that requires that Windows and Mac to also have this
tool, and e.g. on Windows to have that tool in the PATH and pointing to
the
corres
On Tue, Oct 23, 2012 at 08:25:19AM -0700, Thiago Macieira wrote:
> On terça-feira, 23 de outubro de 2012 15.04.10, Oswald Buddenhagen wrote:
> > > Because qdbus should be in /usr/bin but the version- and arch-specific
> > > qmake should be somewhere in /usr/lib*/qt5.
> >
> > ok, i can buy that as
> From: Thiago Macieira
>Subject: Re: [Development] New proposal for the tool naming
>On segunda-feira, 22 de outubro de 2012 21.21.17, André Pönitz wrote:
>> On Mon, Oct 22, 2012 at 09:08:38AM -0700, Thiago Macieira wrote:
>> > On segunda-feira, 22 de outubro
On terça-feira, 23 de outubro de 2012 15.04.10, Oswald Buddenhagen wrote:
> > Because qdbus should be in /usr/bin but the version- and arch-specific
> > qmake should be somewhere in /usr/lib*/qt5.
>
> ok, i can buy that as such.
> however, i totally see no point in us doing this upstream, and why q
Re on adjusting all the documentation to say "run qmake -qt5":
Let's count who will have Qt5 co-/installed:
1) Those who's DE is built against Qt5 and thus Qt5 is the default Qt
there; though, they may have Qt4 co-installed until all the qt-apps
in-use are ported to Qt5;
2) Those who are still on Q
On Mon, Oct 22, 2012 at 01:38:56PM -0700, Thiago Macieira wrote:
> On segunda-feira, 22 de outubro de 2012 20.52.49, Oswald Buddenhagen wrote:
> > > I can't fix what's already broken due to the Qt 3 and Qt 4 mess. I can
> > > only fix going forward for Qt 5.
> > >
> >
> > i fail to see your argu
On segunda-feira, 22 de outubro de 2012 20.52.49, Oswald Buddenhagen wrote:
> > I can't fix what's already broken due to the Qt 3 and Qt 4 mess. I can
> > only fix going forward for Qt 5.
> >
>
> i fail to see your argument here. what exactly is the reason why having
> the "apps" and the "tools"
On segunda-feira, 22 de outubro de 2012 21.21.17, André Pönitz wrote:
> On Mon, Oct 22, 2012 at 09:08:38AM -0700, Thiago Macieira wrote:
> > On segunda-feira, 22 de outubro de 2012 15.45.56, Oswald
> >
> > Buddenhagen wrote:
> > > On Fri, Oct 19, 2012 at 04:16:14PM -0700, Thiago Macieira wrote:
> >
On Mon, Oct 22, 2012 at 09:08:38AM -0700, Thiago Macieira wrote:
> On segunda-feira, 22 de outubro de 2012 15.45.56, Oswald
> Buddenhagen wrote:
> > On Fri, Oct 19, 2012 at 04:16:14PM -0700, Thiago Macieira wrote:
> > > Note: this applies to the *tools* only. The library naming and
> > > installati
On Mon, Oct 22, 2012 at 11:19:17AM -0700, Thiago Macieira wrote:
> On segunda-feira, 22 de outubro de 2012 19.23.23, Oswald Buddenhagen wrote:
> > > > only if you conveniently ignore my two (or three?) mails saying the
> > > > exact
> > > > opposite. the problem with renaming the libraries is the s
On segunda-feira, 22 de outubro de 2012 11.19.17, Thiago Macieira wrote:
> Except if you want the .so files in /usr/lib co-installable with the Qt 4
> ones. Yeah, we could put them in /usr/lib/qt5/lib, but that sounds rather
> convoluted to me. It also introduces multiarch issues, since then we ne
On segunda-feira, 22 de outubro de 2012 19.23.23, Oswald Buddenhagen wrote:
> > > only if you conveniently ignore my two (or three?) mails saying the
> > > exact
> > > opposite. the problem with renaming the libraries is the same as with
> > > tools: project files not based on qmake need to be adju
On Mon, Oct 22, 2012 at 09:08:38AM -0700, Thiago Macieira wrote:
> On segunda-feira, 22 de outubro de 2012 15.45.56, Oswald Buddenhagen wrote:
> > On Fri, Oct 19, 2012 at 04:16:14PM -0700, Thiago Macieira wrote:
> > > Note: this applies to the *tools* only. The library naming and
> > > installation
On segunda-feira, 22 de outubro de 2012 15.45.56, Oswald Buddenhagen wrote:
> On Fri, Oct 19, 2012 at 04:16:14PM -0700, Thiago Macieira wrote:
> > Note: this applies to the *tools* only. The library naming and
> > installation
> > paths for plugins and QML files has remained uncontested so far, so
On segunda-feira, 22 de outubro de 2012 15.19.57, Simon Hausmann wrote:
> > Note: this applies to the tools only. The library naming and installation
> > paths for plugins and QML files has remained uncontested so far, so we
> > appear to have a consensus.
>
> In all fairness, I think Ossi still d
On segunda-feira, 22 de outubro de 2012 19.02.38, Konstantin Tokarev wrote:
> 22.10.2012, 18:49, "Thiago Macieira" :
> > I just have no idea how one thing relates to the other. Can you share a
> > little more about how this solves a problem that you were seeing?
>
> It provides a sane way of coexi
On segunda-feira, 22 de outubro de 2012 14.59.09, Ziller Eike wrote:
> >> Just as a side note, that requires that Windows and Mac to also have this
> >> tool, and e.g. on Windows to have that tool in the PATH and pointing to
> >> the
> >> corresponding Qt for the environment set up shell scripts. I
22.10.2012, 18:49, "Thiago Macieira" :
> On segunda-feira, 22 de outubro de 2012 15.41.19, Konstantin Tokarev wrote:
>
>> 20.10.2012, 03:16, "Thiago Macieira" :
>>> b) additionally, it accepts an extra argument (-select), which causes it
>>> to select a different Qt version. For example:
>>>
On 22 Oct 2012, at 16:47, Thiago Macieira
wrote:
> On segunda-feira, 22 de outubro de 2012 10.59.58, Ziller Eike wrote:
>>> In turn, the official Qt 5 documentation should always talk about qmake
>>> like so:
>>> qmake -qt5 "LIBS+=-L/usr/local/lib -lmysqlclient_r" mysql.pro
>>
>> Just as
On Monday, October 22, 2012 07:50:37 AM Thiago Macieira wrote:
> On segunda-feira, 22 de outubro de 2012 15.19.57, Simon Hausmann wrote:
> > > I haven't decided whether this tool should be a shell script, a perl
> > > script
> > > or another bootstrapped executable.
> >
> > I'm inclined to suggest
On segunda-feira, 22 de outubro de 2012 15.19.57, Simon Hausmann wrote:
> > I haven't decided whether this tool should be a shell script, a perl
> > script
> > or another bootstrapped executable.
>
> I'm inclined to suggest a bootstrapped executable. If it had a shell
> sourcing mode like dbus-la
On segunda-feira, 22 de outubro de 2012 15.41.19, Konstantin Tokarev wrote:
> 20.10.2012, 03:16, "Thiago Macieira" :
> > b) additionally, it accepts an extra argument (-select), which causes it
> > to select a different Qt version. For example:
> > qmake -qt=5 -project
> > qmake -q
On segunda-feira, 22 de outubro de 2012 10.59.58, Ziller Eike wrote:
> > In turn, the official Qt 5 documentation should always talk about qmake
> > like so:
> > qmake -qt5 "LIBS+=-L/usr/local/lib -lmysqlclient_r" mysql.pro
>
> Just as a side note, that requires that Windows and Mac to also
The more I read the various related threads, the more I think if qt-project is
to do anything it should be to define to LSB/FHS how to configure Qt. I don't
necessarily see consensus; but I do see a lot of questions that have gone
unanswered. There seems to be a lot of objection to user tool nam
> From: Konstantin Ritt
> Sent: Sunday, October 21, 2012 5:56 AM
> Subject: Re: [Development] New proposal for the tool naming
>>> > The easiest way to achieve that is probably to create a solution
> based on
>>> > files and you create a ~/.config/qconfi
On Fri, Oct 19, 2012 at 04:16:14PM -0700, Thiago Macieira wrote:
> Note: this applies to the *tools* only. The library naming and installation
> paths for plugins and QML files has remained uncontested so far, so we appear
> to have a consensus.
>
only if you conveniently ignore my two (or three
On Friday, October 19, 2012 04:16:14 PM Thiago Macieira wrote:
> Starting a new thread with some ideas based on the outcomes of the
> discussion. Many thanks to rittk, Simon, Lars and André who helped come up
> with this.
(and Tor Arne!)
> Note: this applies to the *tools* only. The library nami
20.10.2012, 03:16, "Thiago Macieira" :
> b) additionally, it accepts an extra argument (-select), which causes it to
> select a different Qt version. For example:
> qmake -qt=5 -project
> qmake -qt=4.8.4 CONFIG+=debug
I like this idea. Among other benefits, it makes it simpler t
Fine with me, with a comment inline.
++ Eike
On 20 Oct 2012, at 01:16, Thiago Macieira wrote:
> Starting a new thread with some ideas based on the outcomes of the
> discussion.
> Many thanks to rittk, Simon, Lars and André who helped come up with this.
>
> Note: this applies to the *tools* o
On segunda-feira, 22 de outubro de 2012 13.57.36, Lincoln Ramsay wrote:
> Though, I'm not sure we need QT_SELECT. If you can change an environment
> variable, you can modify PATH.
Changing one variable to a specific value is considerably easier than changing
PATH.
> > Additionally, this tool may
Serves me right for not reading _all_ the mail in this folder before
replying to an old thread...
On 20/10/12 09:16, Thiago Macieira wrote:
> a) under most circumstances, it will simply find another qmake and pass
> through all arguments. That is:
> qmake -project
> basically
On Sunday, October 21, 2012 10:51:12 Thiago Macieira wrote:
> > All correct? Did I miss anything?
>
> More or less. I was thinking it might work if it's inside the qtbase
> sources.
> If distros are going to provide Qt 5, they need to compile qtbase
> anyway. The only thing we need is to provide
On domingo, 21 de outubro de 2012 19.06.32, Stephen Kelly wrote:
> I see.
>
> If such a wrapper exists, then:
>
> * It will need to be in a separate package from the Qt 4 and Qt 5 repos
> * It needs to be maintained and released on its own cycle as needed
> ** Supported features of conf files
On Sunday, October 21, 2012 09:32:33 Thiago Macieira wrote:
> On domingo, 21 de outubro de 2012 18.06.46, Stephen Kelly wrote:
> > > The packagers have to change the only Qt4 qmake's name/path and
> >
> > The whole point of this proposal used to be to make it not necessary for
> > distros to patch
On domingo, 21 de outubro de 2012 18.06.46, Stephen Kelly wrote:
> > The packagers have to change the only Qt4 qmake's name/path and
>
> The whole point of this proposal used to be to make it not necessary for
> distros to patch Qt.
>
> This proposal as you state is requires everyone to patch Q
On Sunday, October 21, 2012 09:45:57 you wrote:
> On Sun 21 Oct 2012 05:40:13 Stephen Kelly escribió:
> [snip]
>
> > I get the impression that most people developing against Qt, even on
> > Linux,
> > are using the SDK.
>
> Well, my impression is exactly the contrary: most people developing against
On Sunday, October 21, 2012 12:56:05 Konstantin Ritt wrote:
> >> > Why not use a tool of a new name? Why overload the meaning and
> >> > responsiblity of qmake?
> >
> >
> > If the new tool is to be installed to /usr/bin/qmake and the Qt 4 qmake is
> > today at /usr/bin/qmake, packagers have to ch
On Sun, Oct 21, 2012 at 2:45 PM, Lisandro Damián Nicanor Pérez Meyer <
perezme...@gmail.com> wrote:
> Well, my impression is exactly the contrary: most people developing
> against Qt
> just install the development packages.
>
> In fact, I have never met someone who installed the SDK when [s]he ca
On Sun 21 Oct 2012 05:40:13 Stephen Kelly escribió:
[snip]
> I get the impression that most people developing against Qt, even on Linux,
> are using the SDK.
Well, my impression is exactly the contrary: most people developing against Qt
just install the development packages.
In fact, I have nev
>> > Why not use a tool of a new name? Why overload the meaning and
>> > responsiblity of qmake?
>
> If the new tool is to be installed to /usr/bin/qmake and the Qt 4 qmake is
> today at /usr/bin/qmake, packagers have to change everything in their Qt 4
> packages or they will conflict and not be c
On Saturday, October 20, 2012 09:10:05 Thiago Macieira wrote:
> On sábado, 20 de outubro de 2012 10.28.35, Stephen Kelly wrote:
> > On Saturday, October 20, 2012 10:30:36 Alberto Mardegan wrote:
> > > On 10/20/2012 02:16 AM, Thiago Macieira wrote:
> > > [...]
> > >
> > > > 3) In addition, we'll cre
PM
> Subject: [Development] New proposal for the tool naming
>
> Starting a new thread with some ideas based on the outcomes of the
> discussion.
> Many thanks to rittk, Simon, Lars and André who helped come up with this.
>
> Note: this applies to the *tools* only. The library nam
On sábado, 20 de outubro de 2012 10.28.35, Stephen Kelly wrote:
> On Saturday, October 20, 2012 10:30:36 Alberto Mardegan wrote:
> > On 10/20/2012 02:16 AM, Thiago Macieira wrote:
> > [...]
> >
> > > 3) In addition, we'll create a *new* tool also called qmake that will be
>
> I wonder how FindQt4.c
On Saturday, October 20, 2012 12:12:39 Alberto Mardegan wrote:
> On 10/20/2012 11:28 AM, Stephen Kelly wrote:
> >> And from that time on one doesn't need to remember what qt version or
> >> toolchain one has to use for a project, and just always type "qmake"
> >> from the project base directory.
>
On 10/20/2012 11:28 AM, Stephen Kelly wrote:
>> And from that time on one doesn't need to remember what qt version or
>> toolchain one has to use for a project, and just always type "qmake"
>> from the project base directory.
>
> This is the right goal imo, but the wrong implementation.
I'm not s
On Saturday, October 20, 2012 10:30:36 Alberto Mardegan wrote:
> On 10/20/2012 02:16 AM, Thiago Macieira wrote:
> [...]
>
> > 3) In addition, we'll create a *new* tool also called qmake that will be
I wonder how FindQt4.cmake will react to that. If that module finds Qt 5 it is
supposed to keep l
On 10/20/2012 02:16 AM, Thiago Macieira wrote:
[...]
> 3) In addition, we'll create a *new* tool also called qmake that will be
> installed to $bindir. This tool shall have the following behaviours:
>
> a) under most circumstances, it will simply find another qmake and pass
> through all argume
On sexta-feira, 19 de outubro de 2012 16.16.14, Thiago Macieira wrote:
> 1) we introduce a $libexecdir configuration option to qmake and
> QLibraryInfo. For backwards compatibility, this $libexecdir will receive
> the legacy names of QT_INSTALL_BINS and QLibraryInfo::BinariesPath. It will
> defaul
On sábado, 20 de outubro de 2012 01.31.18, Pau Garcia i Quiles wrote:
> What's "-qt5" ? Latest Qt 5.x.y available? A shorthand for "qmake
> -qt=5.0.0"? Something else?
The latest available or some pre-configured alias. I was hoping to leave that
part for later, until I implement this tool.
My cur
On Sat, Oct 20, 2012 at 1:16 AM, Thiago Macieira
wrote:
> b) additionally, it accepts an extra argument (-select), which causes it
> to
> select a different Qt version. For example:
> qmake -qt=5 -project
> qmake -qt=4.8.4 CONFIG+=debug
> etc.
> As a shorthand, the optio
Starting a new thread with some ideas based on the outcomes of the discussion.
Many thanks to rittk, Simon, Lars and André who helped come up with this.
Note: this applies to the *tools* only. The library naming and installation
paths for plugins and QML files has remained uncontested so far, so w
68 matches
Mail list logo
