Am Mittwoch, 29. April 2020, 21:41:37 CEST schrieb David Faure:
> On lundi 27 avril 2020 14:28:42 CEST Friedrich W. H. Kossebau wrote:
> > Am Sonntag, 26. April 2020, 16:12:31 CEST schrieb Friedrich W. H.
Kossebau:
> > > Am Sonntag, 26. April 2020, 15:46:35 CEST schrieb David Faure:
> > > > On Sun
On lundi 27 avril 2020 14:28:42 CEST Friedrich W. H. Kossebau wrote:
> Am Sonntag, 26. April 2020, 16:12:31 CEST schrieb Friedrich W. H. Kossebau:
> > Am Sonntag, 26. April 2020, 15:46:35 CEST schrieb David Faure:
> > > On Sunday, April 26, 2020 3:21:34 PM CEST René J.V. Bertin wrote:
> > > > Talki
Am Sonntag, 26. April 2020, 16:12:31 CEST schrieb Friedrich W. H. Kossebau:
> Am Sonntag, 26. April 2020, 15:46:35 CEST schrieb David Faure:
> > On Sunday, April 26, 2020 3:21:34 PM CEST René J.V. Bertin wrote:
> > > Talking about version test hacks (or not-so-hacks): why is it that
> > > KFOO_VERS
On Sunday April 26 2020 20:16:33 René J.V. Bertin wrote:
>I was referring to code that just rolls their own implementation of the code
>in almost an given library. It's a bit of a pathological argument but I'd say
>it's beyond argument that you can always do that, whereas even exhaustive
>knowl
On Sunday April 26 2020 18:19:28 David Faure wrote:
>> The possibility to use precompiled headers is only an argument here when
>> increased compilation times are brought up as an argument against such a
>> header. But that's not really an argument if you can continue to use just
>> the headers yo
On Sunday, April 26, 2020 5:50:40 PM CEST René J.V. Bertin wrote:
> On Sunday April 26 2020 16:58:10 David Faure wrote:
> >> As a side-note, I'd even argue that
> >> it would make sense to provide an all-inclusive header per framework,
> >> just
> >> like Apple's frameworks do.
> >
> >It's said to
On Sunday April 26 2020 16:58:10 David Faure wrote:
>> As a side-note, I'd even argue that
>> it would make sense to provide an all-inclusive header per framework, just
>> like Apple's frameworks do.
>
>It's said to improve compilation times with precompiled headers, but in
>practice nobody knows
On Sunday, April 26, 2020 4:32:46 PM CEST René J.V. Bertin wrote:
> On Sunday April 26 2020 15:46:35 David Faure wrote:
> >Well, yeah, you can't have it all.
>
> I suppose that the appropriate ECM could provide a function that returns the
> path to the "official" Qt headers (or an expression that
On Sunday April 26 2020 15:46:35 David Faure wrote:
>Well, yeah, you can't have it all.
I suppose that the appropriate ECM could provide a function that returns the
path to the "official" Qt headers (or an expression that evaluates to that
path) unless something like QT_HEADER_PATH is defined.
Am Sonntag, 26. April 2020, 15:46:35 CEST schrieb David Faure:
> On Sunday, April 26, 2020 3:21:34 PM CEST René J.V. Bertin wrote:
> > Talking about version test hacks (or not-so-hacks): why is it that
> > KFOO_VERSION isn't defined systematically when you include any header of
> > the FOO KF5 fram
On Sunday, April 26, 2020 3:21:34 PM CEST René J.V. Bertin wrote:
> On Sunday April 26 2020 14:12:01 David Faure wrote:
> >> (and possibly LD_PRELOAD).
> >
> >I don't see why you would set LD_PRELOAD in this configuration.
>
> This may be necessary if even one of the multiple libraries that get lo
On Sunday April 26 2020 14:12:01 David Faure wrote:
>> (and possibly LD_PRELOAD).
>
>I don't see why you would set LD_PRELOAD in this configuration.
This may be necessary if even one of the multiple libraries that get loaded has
an old-style link to a Qt library which makes it ignore LD_LIBRARY_
On Saturday, April 25, 2020 2:23:34 PM CEST René J.V. Bertin wrote:
> Hi,
>
> A priori Qt guarantees that you can run binaries against a different, newer
> Qt version than they were built against, as long as no private APIs are
> used. This also works if that newer Qt version is installed elsewher
Hi,
A priori Qt guarantees that you can run binaries against a different, newer Qt
version than they were built against, as long as no private APIs are used. This
also works if that newer Qt version is installed elsewhere, provided you set
LD_LIBRARY_PATH correctly (and possibly LD_PRELOAD). I
Hi Aleix,
On Friday 20 June 2014 01:44:26 Aleix Pol wrote:
> Maybe you have a too new version of cmake? We've seen problems with it.
>
> I've never had to install a file myself (or at least in the last months ;)).
OK, I retried and now it works. Was only a bad time to start ;-)
Cheers,
André
El Divendres, 20 de juny de 2014, a les 07:33:34, Kevin Ottens va escriure:
> Hello,
>
> On Thursday 19 June 2014 22:30:26 André Wöbbeking wrote:
> > I wanted to give KF5 a try and followed the instructions from
> > http://community.kde.org/Frameworks/Building. After Albert told me not to
> > use
Hello,
On Thursday 19 June 2014 22:30:26 André Wöbbeking wrote:
> I wanted to give KF5 a try and followed the instructions from
> http://community.kde.org/Frameworks/Building. After Albert told me not to
> use Clang most of it compiled without any problem.
Actually if it breaks with Clang it shou
On Thu, Jun 19, 2014 at 10:30 PM, André Wöbbeking
wrote:
> Hi,
>
> I wanted to give KF5 a try and followed the instructions from
> http://community.kde.org/Frameworks/Building. After Albert told me not to
> use
> Clang most of it compiled without any problem. But I had to install these
> files
>
Hi,
I wanted to give KF5 a try and followed the instructions from
http://community.kde.org/Frameworks/Building. After Albert told me not to use
Clang most of it compiled without any problem. But I had to install these
files
frameworks/kio/src/core/kssl/ksslsettings.h
frameworks/ktextwidgets/s
On Tuesday 04 March 2014 20:52:45 Michael Pyne wrote:
> On Tue, March 4, 2014 22:56:03 Dominik Haumann wrote:
> > Building KF5 mostly works, except I now get the error (cleaned build +
> > install folder) below when building kate. It looks as if Qt4 is somehow in
> > the way n
On Tue, March 4, 2014 22:56:03 Dominik Haumann wrote:
> Building KF5 mostly works, except I now get the error (cleaned build +
> install folder) below when building kate. It looks as if Qt4 is somehow in
> the way now. This used to work before, so is there any way to get it
> workin
Building KF5 mostly works, except I now get the error (cleaned build + install
folder) below when building kate. It looks as if Qt4 is somehow in the way now.
This used to work before, so is there any way to get it working again?
The detailed cmake logs are on paste.kde.org (see below
On Friday 30 November 2012, Jon Severinsson wrote:
> At Friday 30 November 2012 19:09:26 David Faure wrote:
> > On Friday 30 November 2012 17:14:15 Jon Severinsson wrote:
> > > Small (but important) correction, this line should be:
> > > $ cmake -DCMAKE_INSTALL_PREFIX=«installdir»
> > > -DCMAKE_SYS
At Friday 30 November 2012 19:09:26 David Faure wrote:
> On Friday 30 November 2012 17:14:15 Jon Severinsson wrote:
> > Small (but important) correction, this line should be:
> > $ cmake -DCMAKE_INSTALL_PREFIX=«installdir»
> > -DCMAKE_SYSTEM_PREFIX_PATH=/usr:/usr/local:«installdir» ..
>
> I don't
On Friday 30 November 2012 17:14:15 Jon Severinsson wrote:
> At Friday 30 November 2012 12:12:22 David Faure wrote:
> > Please update http://community.kde.org/Frameworks/Building,
> > in the "building with Qt5" section.
>
> Done
>
> > On Friday 30 November 2012 10:41:23 Jon Severinsson wrote:
> >
At Friday 30 November 2012 12:12:22 David Faure wrote:
> Please update http://community.kde.org/Frameworks/Building,
> in the "building with Qt5" section.
Done
> On Friday 30 November 2012 10:41:23 Jon Severinsson wrote:
> $ cmake -DCMAKE_INSTALL_PREFIX=«installdir» -
DCMAKE_SYSTEM_PREFIX_PATH=«i
On Friday 30 November 2012 10:41:23 Jon Severinsson wrote:
> Just a note to everyone building KF5 on Qt5.
>
> If you have any phonon version installed on your system, KF5 will now try to
> use it. If said phonon version was build on Qt4 (say the phonon version
> from your dist
Just a note to everyone building KF5 on Qt5.
If you have any phonon version installed on your system, KF5 will now try to
use it. If said phonon version was build on Qt4 (say the phonon version
from your distro), that won't work as it would pull Qt4 in addition to Qt5.
To fix this, e
28 matches
Mail list logo
