On 20/10/12 07:35, Thiago Macieira wrote:
> Really, I don't care what qmake5 is and where it points to, so long as:
> a) it exists
> b) it works
> c) it's the official and documented way of creating Qt applications in Qt 5
>
> Any other names are under the customer's taste.
Surely then the v
On sábado, 20 de outubro de 2012 08.38.20, Lorn Potter wrote:
> > The distros *will* apply renaming. And without our help, they may
> > introduce
> > bugs and they will be definitely deviating from the documented way.
>
> Then that's their problem, not qt-projects.
I don't see it that way and I do
On 20/10/12 7:37 AM, Thiago Macieira wrote:
> On sábado, 20 de outubro de 2012 05.00.53, Lorn Potter wrote:
>> I won't add anything but my support for leaving it alone. Let the Linux
>> distributions solve their own problems, which they already have.
>
> Once again: the problem may have originated
On sábado, 20 de outubro de 2012 05.00.53, Lorn Potter wrote:
> I won't add anything but my support for leaving it alone. Let the Linux
> distributions solve their own problems, which they already have.
Once again: the problem may have originated with the distros and their rules,
but that affects
On sexta-feira, 19 de outubro de 2012 19.32.05, Laszlo Papp wrote:
> I have not personally been much fan of that schema... Thiago, I hope
> your next proposal will not be qmake5.0, qmake5.1 and the like based
> upon some "python precedence".
Even though python does install python3.2 and python3.3,
> Distros would configure Qt with -prefix /usr -bindir /usr/lib/qt5/libexec etc.
Let's make it more flexible for those who will configure:
I'd rather -prefix /usr -bindir /usr/bin -libexecdir /usr/lib/qt5/libexec
since /usr/bin is still an important path where one would expect to
find some scripts
On 19/10/12 21:24, Simon Hausmann wrote:
> (3) This leaves us with the command line tools such as qmake, moc and uic
> where we have a conflict_only_ on Linux when they're installed by
> distributions in /usr/bin.
>
> In short: We find that there is no_need_ to rename the tools and that we can
>
On Fri, Oct 19, 2012 at 7:13 PM, Thiago Macieira
wrote:
> On sexta-feira, 19 de outubro de 2012 13.24.37, Simon Hausmann wrote:
>> Regardless of the solution we find for Qt distro packages, it seems
>> sensible that the Qt users can continue to find a /usr/bin/qmake program
>> that corresponds to
On sexta-feira, 19 de outubro de 2012 13.24.37, Simon Hausmann wrote:
> Regardless of the solution we find for Qt distro packages, it seems
> sensible that the Qt users can continue to find a /usr/bin/qmake program
> that corresponds to the most recent release of Qt. This provides
> consistency wi
On Fri, Oct 19, 2012 at 03:01:05PM +0200, Simon Hausmann wrote:
> Wouldn't it be kind of weird though if the libQtCore.so symlink would live in
> say /usr/lib/qt5/lib but libQtCore.so.5.0.0 itself would be locacted in
> /usr/lib?
>
no, because libQtCore.so.5.0.0 would also live in /usr/lib/qt5/
On Friday, October 19, 2012 02:24:09 PM Oswald Buddenhagen wrote:
> On Fri, Oct 19, 2012 at 01:24:37PM +0200, Simon Hausmann wrote:
> > (1) It seems that there is an agreement on the naming of the libraries and
> > pkg-config files.
>
> not really. i'm not as strongly opposed to it as to renaming
On Fri, Oct 19, 2012 at 01:24:37PM +0200, Simon Hausmann wrote:
> (1) It seems that there is an agreement on the naming of the libraries and
> pkg-config files.
>
not really. i'm not as strongly opposed to it as to renaming the tools,
but i think renaming the libraries is mostly counterproductive
On Thursday, October 18, 2012 08:30:03 AM Thiago Macieira wrote:
[...]
Tor Arne and I have been discussing this once more and we'd like to make an
alternative proposal. But first let's try to summarize.
(1) It seems that there is an agreement on the naming of the libraries and
pkg-config files.
13 matches
Mail list logo
