> On 2 Aug 2018, at 08:13, BogDan Vatra via Development
> wrote:
> […]
> It will be nice if this feature is mandatory for Qt 6, so let's add it to
> your requirements list.
Let’s be careful not to add too many requirements upfront or we’ll never get
anywhere.
For me the hard requirements
> On 2 Aug 2018, at 08:38, BogDan Vatra via Development
> wrote:
>
> Hi
> În ziua de joi, 2 august 2018, la 09:33:10 EEST, Joerg Bornemann a scris:
>> On 08/02/2018 08:18 AM, Simon Hausmann wrote:
>>> Given that the output of the moc changes depending on what platform and
>>> compiler dependent
Hi
În ziua de joi, 2 august 2018, la 09:33:10 EEST, Joerg Bornemann a scris:
> On 08/02/2018 08:18 AM, Simon Hausmann wrote:
> > Given that the output of the moc changes depending on what platform and
> > compiler dependent pre-processor macros are supplied, I would say that
> > the output is not c
On 08/02/2018 08:18 AM, Simon Hausmann wrote:
Given that the output of the moc changes depending on what platform and
compiler dependent pre-processor macros are supplied, I would say that the
output is not cross-platform.
...which is why qbs does *not* have such a feature.
moc_XXX.cpp and X
On 2 Aug 2018, at 00:27, Thiago Macieira
mailto:thiago.macie...@intel.com>> wrote:
On Wednesday, 1 August 2018 13:14:32 PDT Sérgio Martins wrote:
On Sat, Jul 21, 2018 at 3:35 AM, Thiago Macieira
mailto:thiago.macie...@intel.com>> wrote:
Hello
Having spent far too much time trying to figure out
Hi,
Given that the output of the moc changes depending on what platform and
compiler dependent pre-processor macros are supplied, I would say that the
output is not cross-platform.
Simon
>> On 2. Aug 2018, at 00:31, Thiago Macieira wrote:
>>
>> On Wednesday, 1 August 2018 12:46:04 PDT BogDan
Hi,
În ziua de joi, 2 august 2018, la 01:31:10 EEST, Thiago Macieira a scris:
> On Wednesday, 1 August 2018 12:46:04 PDT BogDan Vatra via Development wrote:
> > Hi,
> >
> > qmake can't compile them all *at once* e.g. $ qmake && make will compile
> > only one target at the time not all.
> >
> > AF
Bazel's caching mechanism would also optimize away regeneration of
generated outputs (via genrules) across the different toolchains,
provided the tools/scripts and important environmental variables/files
do not change (which would hash to different keys). Further you could
run a disk local cache o
On Wednesday, 1 August 2018 12:46:04 PDT BogDan Vatra via Development wrote:
> Hi,
>
> qmake can't compile them all *at once* e.g. $ qmake && make will compile
> only one target at the time not all.
>
> AFAIK QBS and iirc gn too, are the only few that have this cool feature.
Now that is nice, as
On Wednesday, 1 August 2018 13:14:32 PDT Sérgio Martins wrote:
> On Sat, Jul 21, 2018 at 3:35 AM, Thiago Macieira
>
> wrote:
> > Hello
> >
> > Having spent far too much time trying to figure out why crappy
> > buildsystems
> > cause failures in distros (like TensorFlow or libvpx - see
> > https:
On Tue, Jul 31, 2018 at 02:51:41PM +0200, Giuseppe D'Angelo via Development
wrote:
> Hi,
>
> On 31/07/18 13:11, Sérgio Martins via Development wrote:
> > I would recommend however that our docs show T* instead of gsl::owner
> > and continue to include "Takes ownership of foo" in the text.
> > Whi
On Wed, Aug 1, 2018 at 8:46 PM, BogDan Vatra via Development
wrote:
> Hi,
>
> qmake can't compile them all *at once* e.g. $ qmake && make will compile
> only one target at the time not all.
>
> AFAIK QBS and iirc gn too, are the only few that have this cool feature.
And probably do a single moc a
On Sat, Jul 21, 2018 at 3:35 AM, Thiago Macieira
wrote:
> Hello
>
> Having spent far too much time trying to figure out why crappy buildsystems
> cause failures in distros (like TensorFlow or libvpx - see
> https://plus.google.com/+ThiagoMacieira/posts/DqTKdRGfuwR ), I'd like to make
> sure this d
Hi,
qmake can't compile them all *at once* e.g. $ qmake && make will compile only
one target at the time not all.
AFAIK QBS and iirc gn too, are the only few that have this cool feature.
Cheers,
BogDan.
On August 1, 2018 10:27:03 PM GMT+03:00, Thiago Macieira
wrote:
>On Wednesday, 1 August 2
On Wednesday, 1 August 2018 11:58:02 PDT BogDan Vatra via Development wrote:
> Hi,
>
> Did you knew that qbs can build all but windows targets at once from your
> Linux machine?
That's not news. qmake can do that, provided you have the toolchains. You
could compile for Mac and MSVC too, if yo
Hi,
Did you knew that qbs can build all but windows targets at once from your
Linux machine? Using mingw you can cross compile Qt for windows, but you
probably want to run tests and to check if the code compiles with msvc.
This feature might not seem pretty useful for linux, but is very usef
On Tuesday, 31 July 2018 07:52:37 PDT Thiago Macieira wrote:
> Well, it could be much worse. There are a couple of low-hanging fruits
> there that we can easily fix. I'll take a look later today on those
> applying to QtCore.
Done almost all for qtbase, from Kai's listing:
https://codereview.qt-
On Wednesday, 1 August 2018 06:48:40 PDT Tor Arne Vestbø wrote:
> > On 1 Aug 2018, at 15:45, Kai Koehne wrote:
> >
> > Alright, so it seems we have to prefix the symbols we can't hide by static
> > or anonymous namespaces ...
> > For logging categories, I'd like to start using 'qlc' as prefix.
On Wednesday, 1 August 2018 02:01:40 PDT Edward Welbourne wrote:
> This is easy to do in any build system that supports out-of-source
> (a.k.a. "shadow") builds - notably including the existing qmake-based
> builds for Qt. I never want to do an in-source build of anything.
And not just that. Buil
Hi everyone,
While trying to submit a patch to fix QStringListModel::setItemData
https://codereview.qt-project.org/235730 we opened a much larger discussion on
QAbstractItemModel, that expanded on the forum
https://forum.qt.io/topic/93207/qabstractitemmodel-setitemdata-partial-success
but that
On 1 August 2018 at 11:24, Jason Newton wrote:
>> And... seriously, *Java*?! Talk about bloat-ware... As dependencies for
>> *a build tool* go, that's pretty insane. Especially if you're not
>> planning to use it to build Java code.
>
> As I said, ~300-400 megabytes for a JRE (~90MiB DL), in parti
On 2018-08-01 04:24, Jason Newton wrote:
> On Mon, Jul 30, 2018 at 1:30 PM Matthew Woehlke wrote:
>> On 2018-07-21 19:52, Jason Newton wrote:
>>> I wanted to mention that this is on my mind alot for a few years days
>>> as a user for a plethora of libraries. My conclusion for the build
>>> system
> On 1 Aug 2018, at 15:45, Kai Koehne wrote:
>
> Alright, so it seems we have to prefix the symbols we can't hide by static or
> anonymous namespaces ...
>
> For logging categories, I'd like to start using 'qlc' as prefix. See also
> change https://codereview.qt-project.org/#/c/235631/ for q
Alright, so it seems we have to prefix the symbols we can't hide by static or
anonymous namespaces ...
For logging categories, I'd like to start using 'qlc' as prefix. See also
change https://codereview.qt-project.org/#/c/235631/ for qtbase.
Ossi pointed out in the review that, because it is a
Singling out just one tiny corner of all that for a passing remark:
Jason Newton (1 August 2018 10:24)
> One of the things I like about the way bazel keeps this is I can jump
> back and forth between an optimized build and a full debug build (for
> example) - they don't erase eachother
This is ea
On Mon, Jul 30, 2018 at 1:30 PM Matthew Woehlke
wrote:
>
> On 2018-07-21 19:52, Jason Newton wrote:
> > I wanted to mention that this is on my mind alot for a few years days
> > as a user for a plethora of libraries. My conclusion for the build
> > system with the brightest future is bazel [...]
Sounds good to me.
Cheers,
Lars
On 27 Jul 2018, at 14:37, Tilman Röder
mailto:tilman.ro...@qt.io>> wrote:
Hello there,
My name is Tilman and I am a software engineering intern at the Qt office in
Berlin. I'm working on combining PySide2, Shiboken and QtCreator to enable
Python based extensio
27 matches
Mail list logo
