On 16/06/2023 07:49, Marc Mutz via Development wrote:
On 14.06.23 08:33, Marc Mutz via Development wrote:
Two more data points:
It doesn't matter whether I write Q_FOO_EXPORT [[nodiscard]] or
[[nodicard]] Q_FOO_EXPORT, I always get an error on some compiler.
Make sure you're not hitting
htt
On 15/06/2023 23:34, Thiago Macieira wrote:
On Thursday, 15 June 2023 15:23:47 PDT Stephen Kelly wrote:
And, you can introduce it in a way which is source-compatible until the
user upgrades their compiler to a compiler version which implements
`using enum`:
https://godbolt.org/z/4EWjWhvfa
On 15/06/2023 22:20, Allan Sandfeld Jensen wrote:
On Mittwoch, 14. Juni 2023 22:53:13 CEST Thiago Macieira wrote:
On Wednesday, 14 June 2023 12:49:22 PDT Allan Sandfeld Jensen wrote:
As discussed earlier. Better naming in many cases until we can depend on
C++20 in API.
There's nothing in C++2
> -Original Message-
> From: Development On Behalf Of
> Thiago Macieira
> Sent: Wednesday 13 February 2019 16:36
> To: development@qt-project.org
> Subject: Re: [Development] CMake Workshop Summary
>
> On Wednesday, 13 February 2019 05:58:18 PST Kevin Funk via Development
> wrote:
> > T
Simon Hausmann
Sent: Wednesday 13 February 2019 12:53
To: Stephen Kelly ; Vitaly Fanaskov
; development@qt-project.org
Subject: Re: [Development] CMake Workshop Summary
I think the deliberate design choice to separate Qt4 and 5 visibly in the "API"
(targets) was a wise choice at that
As a deliberate design choice years ago, we put the major version in the
package name because it avoids a class of user errors and confusion, and
because it allows a single buildsystem with targets linking to either Qt 4 or
Qt 5 (CMake ensures that nothing attempts to link to both).
Thanks,
S
> Have a super-project that allows building all of Qt with one call to "cmake",
> a call to "cmake --build" and finally "$maketool install".
Note that instead of "$maketool install" you could recommend the portable
"cmake --build . --target install". I don't think msbuild accepts a 'install'
a
> The plan for allowing people to develop apps that work with Qt 5 and Qt 6 is
> quite simple API wise:
>
> (1) In your application use either find_package(Qt5) or
> find_package(Qt6)
Will this support COMPONENTS? I would never recommend using COMPONENTS because
it can get odd in the ca
Tomasz Siekierda wrote:
> On Mon, 29 Oct 2018 at 13:31, Tobias Hunger wrote:
>>
>> Hi!
>> [...]
>> # Building
>>
>> The basic way of building with cmake is as follows:
>>
>> ```
>> cd {build directory}
>> cmake {path to source directory}
>> cmake --build .
>> ```
>
> Just a quick
s low change volume).
>
>
> Finally, a big thanks to the previous maintainer, Stephen Kelly, who did
> a great job, both on Qt and KDE models!
+1 for David from me too!
Greetings,
Steve.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Thiago Macieira wrote:
> On segunda-feira, 30 de outubro de 2017 08:27:02 PDT Konstantin Tokarev
> wrote:
>> >> $ cmake --find-package -DNAME=Qt5Core -DCOMPILER_ID=GNU
>> >> -DLANGUAGE=CXX -DMODE=COMPILE
>> >> -I/home/apol/devel/kde5/include/
>> >> -I/home/apol/devel/kde5/include/QtCore
>> >>
André Pönitz wrote:
>
>
> Hi all.
>
> I would like to nominate Kevin Funk for Maintainer of the
> Build Systems/CMake area.
>
> Kevin is effectively doing the job today.
+1 from me too.
Thanks Kevin!
___
Development mailing list
Development@qt-pro
> The approaches available currently either
>
> 1) scale everything after rendering (eg with SetProcessDPIAware())
> 2) scale coordinates to screen metrics before rendering
> (QApplication::setAttribute(Qt::AA_EnableHighDpiScaling))
>
> The first approach gives a blurry result because of up/down
> It's not like devices change DPI, though if
> you have multiple monitors this assumption may be invalid if the user moves
> the window to between screens or another screen.
This is indeed the topic of this thread. The other issues you raise look like
they should be raised on another thread.
Th
> From: doom.ooseve...@gmail.com [mailto:doom.ooseve...@gmail.com] On Behalf Of
> Jean-Michaël Celerier
> Sent: Friday 22 September 2017 13:25
> To: Stephen Kelly
> Cc: Jean-Michaël Celerier ;
> development@qt-project.org
> Subject: Re: [Development] New approach to
[mailto:doom.ooseve...@gmail.com] On Behalf Of
Jean-Michaël Celerier
Sent: Thursday 21 September 2017 11:29
To: Stephen Kelly
Cc: development@qt-project.org
Subject: Re: [Development] New approach to hi-dpi and coordinate system for
layouts in Qt 6
> making it impossible to specify 'a one/two pixe
Hi,
Qt 5 has several approaches to attempting to size/scale a UI when moving
between screens which have
different APIs. There is a summary here:
https://vicrucann.github.io/tutorials/osg-qt-high-dpi/
The approaches available currently either
1) scale everything after rendering (eg with SetPr
Marc Mutz wrote:
> Hi,
>
> I just filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433
> complaining that __has_include returns true for headers which then, when
> included, #error out about the wrong C++ standard used.
In my opinion, the problem is sd-6 defining feature macros in the header
Hi,
Does anyone know why QFlags has a constructor taking a Zero pointer? My
guess is that it's a hack to make initializing like
Qt::WindowFlags = 0
work? The problem encountered is that porting tools convert that to
Qt::WindowFlags = nullptr
which is undesirable.
https://mail.kde.org/pip
On 16/09/16 03:07, Christian Kandeler wrote:
Stephen Kelly wrote:
My previous guess about Qbs being able to generate unknown files in a
particular location and then determine them by an 'ls' equivalent, moc
them and compile everything is not something Qbs would be able to do.
On 15/09/16 08:57, Oswald Buddenhagen wrote:
On Wed, Sep 14, 2016 at 12:05:15PM +0200, Stephen Kelly via Development wrote:
I want to understand Qbs and what it can do with a dynamic build graph
which CMake can't do.
there is no such thing
Oh, I'm very surprised by that.
That
On 13/09/16 22:29, Christian Kandeler wrote:
Stephen Kelly wrote:
There is no input file. There is only an input number. The task is from
Bo, who gave it as a simplified example.
Oops, I'm wrong here. Bo said to read the number from a file.
I don't think that changes anyth
Stephen Kelly wrote:
> Christian Kandeler wrote:
>
>> [Sorry about the formatting, using outlook]
>>
>> Stephen Kelly wrote:
>>> Here's the CMake version:
>>
>> [ ... ]
>>
>>> execute_process(
>>
Konstantin Tokarev wrote:
>> -Qbs has great features that you can't find in other build systems (e.g.
>> it can build multiple ABIs/platforms at once).
>
> For the record, premake can do it as well.
Can you show me the syntax for this with premake (and with Qbs)? I assume
you're talking about b
Christian Kandeler wrote:
> [Sorry about the formatting, using outlook]
>
> Stephen Kelly wrote:
>> Here's the CMake version:
>
> [ ... ]
>
>> execute_process(
>> COMMAND python ${CMAKE_CURRENT_SOURCE_DIR}/generator.py --list
&
Hi Edward,
You copied the line:
(Stephen) "In reality, rewriting Qt's build system in CMake will
actually be a PITA, and will require changes to CMake to make everything
better"
That was a stenography error. Can you remove it?
Thanks,
On 12/09/16 16:08, Edward Welbourne wrote:
Fo
On 08/09/16 14:34, Christian Kandeler wrote:
On 09/08/2016 02:03 PM, Bo Thorsen wrote:
Ok, go try it. Create a simple python or perl script that reads a file.
The file just has a single number N inside it. And based on N the script
outputs those files:
Here's the CMake version:
cmake_mi
On 08/09/16 14:34, Christian Kandeler wrote:
On 09/08/2016 02:03 PM, Bo Thorsen wrote:
Ok, go try it. Create a simple python or perl script that reads a file.
The file just has a single number N inside it. And based on N the script
outputs those files:
Here's the CMake version:
cmake_
On 08/09/16 14:48, Milian Wolff wrote:
Someone else also told me that this is apparently harder then I thought it is
with CMake, when the name of the output files of a code generator is not
known. It is possible, but far from easy esp. when you don't have control over
the generator script (thoug
On 06/09/16 20:30, Cristian Adam wrote:
Maybe "bad feedback" is strong, but it was non constructive and lead
to the removal of the Qbs generator.
To clarify even further: the contribution was wip, the contributor was
surprised at it being merged, and happy with it being reverted:
https:
On 06/09/16 20:30, Cristian Adam wrote:
Maybe "bad feedback" is strong, but it was non constructive and lead
to the removal of the Qbs generator.
To clarify even further: the contribution was wip, the contributor was
surprised at it being merged, and happy with it being reverted:
https
On 06/09/16 02:13, Thiago Macieira wrote:
Em segunda-feira, 5 de setembro de 2016, às 12:40:54 PDT, Stephen Kelly via
Development escreveu:
I think something was lost in transit on this point. I don’t think it would
be a PITA to write a CMake buildsystem for Qt. I recall the above point was
Thanks Andrew for these notes! You did really well to capture the key points
from a complex and meandering discussion.
>- (Stephen) "In reality, rewriting Qt's build system in CMake will
>actually be a PITA, and will require changes to CMake to make everything
>better"
I think something
Thiago Macieira wrote:
> On sábado, 2 de julho de 2016 12:40:53 PDT Stephen Kelly wrote:
>> So, by sticking to lots of raw loops, you're actually actively excluding
>> other parts of the C++ community from participating. I don't have numbers
>> to qualify it, but
Thiago Macieira wrote:
> What do we do?
{
int container[1];
Q_ASSERT(!qIsEmpty(container));
}
{
std::vector container;
Q_ASSERT(qIsEmpty(container));
}
{
std::deque container;
Q_ASSERT(qIsEmpty(container));
}
{
std::list container;
Q_ASS
Benjamin TERRIER wrote:
>> However, everyone else is excluded by it. When my colleagues find long
>> functions, lots of nested if()s and for()s, ++foo somewhere in while
> loops,
>> they find it much harder to reason about the code. Now I do too.
>>
>> So, by sticking to lots of raw loops, you're
Stephen Kelly wrote:
> Thiago Macieira wrote:
>
>> More to the point, Qt developers don't have to know the Standard Library.
>> *I* don't and I don't have time or interest in learning it.
>
> There is a big division within the C++ community. There is th
Thiago Macieira wrote:
> More to the point, Qt developers don't have to know the Standard Library.
> *I* don't and I don't have time or interest in learning it.
There is a big division within the C++ community. There is the Qt way and
the non-Qt way, and they don't overlap.
The approach of many
owse/QTBUG-46488
it doesn't seem to be related to the number of items shown.
But anyway these are really important bugs for those who use ListView+QAIM
2016-05-18 13:38 GMT+02:00 Stephen Kelly via Development
mailto:development@qt-project.org>>:
This can also be reproduced wit
This can also be reproduced with ListView instead of TreeView:
https://bugreports.qt.io/browse/QTBUG-53263
Thanks,
Stephen
On 18/05/16 12:21, Filippo Cucchetto wrote:
Hello everyone,
i would like to warn about this serious bug in QDeclarative that could hit
users of ListViews with QAIM
htt
Thiago Macieira wrote:
> On sábado, 19 de março de 2016 19:02:08 GMT Stephen Kelly wrote:
>> Hi,
>>
>> In case you missed it, I wrote an auto-modernizer
>>
>> https://steveire.wordpress.com/2016/03/19/aaargh
>>
>> It is not quite A
Matthew Woehlke wrote:
> On 2016-03-19 14:02, Stephen Kelly wrote:
>> In case you missed it, I wrote an auto-modernizer
>>
>> https://steveire.wordpress.com/2016/03/19/aaargh
>
> Thanks for sharing. I admiringly adore all the abounding (and artistic)
> alliteratio
Hi,
In case you missed it, I wrote an auto-modernizer
https://steveire.wordpress.com/2016/03/19/aaargh
It is not quite AAA, as it doesn't convert
QString s;
into
auto s = QString();
I used it to port qtbase to an extensive use of auto:
https://github.com/steveire/qtbase/commits/aaa
T
Fabrice Salvaire wrote:
> Dear all,
>
> I am investigating to port a content server to an off-line mobile
> application in order to don't rely to a network connection at all. Thus
> I have to port a database, a kind of web framework, a template engine
> and a rendering engine. I believe it can be
On 20/02/16 13:19, Alberto Mardegan wrote:
Hi all!
Since Qt 5.5, the QItemSelectionModel class is exposed to QML as
ItemSelectionModel (in the QtQml.Models module):
http://doc.qt.io/qt-5/qml-qtqml-models-itemselectionmodel.html
Apart from having almost no documentation, this component seem
Hausmann Simon wrote:
> Hi,
>
> Hmm, change https://codereview.qt-project.org/#/c/147846/ was supposed
> to fix this issue.
>
> The subject of the email refers to 5.6 but in the body you say that you
> are building the dev branch. If it is the latter, could it be that the fix
> hasn't hit dev
Hello,
I built Qt dev branch with GCC.
Then I tried to use it to build any trivial shared library with Clang:
stephen@hal:/tmp/qmake$ make CXX=clang++ LINK=clang++ -B
makeobj[0]: Entering directory `/tmp/qmake'
/home/stephen/dev/prefix/qtbase/bin/qmake -o Makefile qmake.pro
clang++ -c -pipe -g
On 21/01/16 14:56, Stephen Kelly wrote:
* Something else
As Andre wrote, 'something else' could be 'populate a "memory structure"
for all roles for the specific rows being removed in response to
rowsAboutToBeRemoved'.
--
Ableton AG, Schoenhauser Al
On 21/01/16 08:12, André Somers wrote:
Actually, I think it would not need to be quite as bad.
For starters, you really only need to cache the actual items being
removed. At the moment the model emits the AboutToBeRemoved signal,
the data should still be there in any well-behaved model, righ
On 21/01/16 00:45, Andrew den Exter wrote:
On Thu, Jan 21, 2016 at 2:11 AM, Stephen Kelly
mailto:stephen.ke...@ableton.com>> wrote:
And there are the obvious runtime costs to building and
maintaining a cache that is of little or no use to most people
most of the time,
On 20/01/16 01:23, Andrew den Exter wrote:
On Wed, Jan 20, 2016 at 2:13 AM, Stephen Kelly
mailto:stephen.ke...@ableton.com>> wrote:
The solution could be to cache data retrieved from the model.
That's a more complex solution than you might think. It's a pretty
po
On 19/01/16 14:17, Stephen Kelly wrote:
Hi,
I have uploaded a testcase to
https://github.com/ske-ableton/public_sscce/tree/master/delegate_data
which demonstrates a problem that can occur with ListView delegates
that can be animated away on removal.
I got feedback that what is
Hi,
I have uploaded a testcase to
https://github.com/ske-ableton/public_sscce/tree/master/delegate_data
which demonstrates a problem that can occur with ListView delegates that
can be animated away on removal.
This seems to me to be a design bug in the QML ListView. It seems to be
a simpl
Konstantin Ritt wrote:
> Maybe JSON.stringify(obj) is what you need?
>
I think the intention is to override what that does using a specified
method.
Thanks,
Steve.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org
Frederik Gladhorn wrote:
> As you know we cannot change the major version as that is not binary
> compatible
I still see no reason for that to be belived to be true.
Of course you can fix the major version number and bump the version in the
SONAME. That's the whole point of the version in the
On Wed, Jul 1, 2015 at 5:11 PM, Olivier Goffart wrote:
> On Wednesday 1. July 2015 16:50:09 Stephen Kelly wrote:
>> Hello,
>>
>> I just tried building Qt 5.5 with Xcode 6.3.2. It built, but emitted
>> many warnings for each translation unit about
>> -Winconsi
Hello,
I just tried building Qt 5.5 with Xcode 6.3.2. It built, but emitted
many warnings for each translation unit about
-Winconsistent-missing-override.
In file included from
/Users/ske/dev/src/qt55/qtdeclarative/src/qml/debugger/qqmldebugserver.cpp:34:
In file included from
/Users/ske/dev/src/
Thiago Macieira wrote:
>> In case anyone else runs into this issue.
>
> That's QTBUG-45755 and its duplicates.
>
> Downgrade the compiler or upgrade to Qt to include the change that rejects
> using -fPIE.
Ah, great, thanks,
Steve.
___
Development m
Hello,
Using this testcase:
#include
#include
#include
int main(int argv, char **args)
{
QCoreApplication app(argv, args);
qDebug() << QCoreApplication::instance() << qApp;
QTimer::singleShot(0, qApp, SLOT(quit()));
return app.exec();
}
and building with ubuntu Qt pac
Knoll Lars wrote:
> * Generic and duplicated names from different namespaces can
> easily lead to confusion when reading code.
... and when searching about information about a class by unqualified name.
'QTransform' is now ambiguous to google. If the namespace route is used for
existing modules
Stephen Kelly wrote:
>> I said I'm happy to discuss. I'm just waiting for some more opinions,
>> please don't take that as me trying to shut the discussion down. :)
>
> Cool. Let's wait and see.
This thread has gone way off-topic now, but we gathered a week
Sean Harmer wrote:
>> I don't know. As far as I know deciding to use a namespace for this one
>> was done without discussion on the mailing list?
>
> There has been at least some discussion of namespaces in the past. For
> e.g.
>
> http://lists.qt-project.org/pipermail/development/2012-August/00
Sean Harmer wrote:
> On Thursday 11 June 2015 19:42:55 Stephen Kelly wrote:
>> Marc Mutz wrote:
>> > On Thursday 11 June 2015 13:09:39 Stephen Kelly wrote:
>> >> I didn't make any claim that "the use of a namespace for a Qt library
>> >> is
Marc Mutz wrote:
> On Thursday 11 June 2015 13:09:39 Stephen Kelly wrote:
>> I didn't make any claim that "the use of a namespace for a Qt library is
>> new".
>>
>> Whatever you rebutted was not my claim.
So, you believe there is no use in pursuing
On Thu, Jun 11, 2015 at 12:29 PM, Marc Mutz wrote:
> I was listing namespaces that are used in Qt already. That was to rebut your
> claim that the use of a namespace for a Qt library is new.
I didn't make any claim that "the use of a namespace for a Qt library is new".
Whatever you rebutted was
On Thu, Jun 11, 2015 at 11:49 AM, Marc Mutz wrote:
> On Wednesday 10 June 2015 21:03:32 Stephen Kelly wrote:
>> I would encourage a discussion of why this module needs namespaces when
>> the rest of Qt gets by without them. There is certainly a consistency
>> angle.
>
Stephen Kelly wrote:
> Sean Harmer wrote:
>
>>> 1) The include/Qt3DCore/Window file doesn't have a Q prefix.
>>>
>>> as every other header does. Should probably be Qt3DWindow.
>>
>> Right, this actually needs removing and something tem
Stephen Kelly wrote:
> Sean Harmer wrote:
>
>>> 1) The include/Qt3DCore/Window file doesn't have a Q prefix.
>>>
>>> as every other header does. Should probably be Qt3DWindow.
>>
>> Right, this actually needs removing and something tem
Sean Harmer wrote:
>> 1) The include/Qt3DCore/Window file doesn't have a Q prefix.
>>
>> as every other header does. Should probably be Qt3DWindow.
>
> Right, this actually needs removing and something temporary putting in
> place in the examples for now.
> I'll try to tidy up and move the exi
On Tue, Jun 9, 2015 at 11:01 AM, Sean Harmer wrote:
> On Monday 08 Jun 2015 14:18:33 Sean Harmer wrote:
>>
>> On Monday 08 Jun 2015 01:11:23 Stephen Kelly wrote:
>> > 2) A private header is included in a public header:
>> > include/Qt3DCore$ grep private/ *.h
&
Hello,
Congrats to Paul, Sean and others working on getting this module in a
releasable state for Qt 5.5!
I have not reviewed the code, but I found some items to raise:
1) The include/Qt3DCore/Window file doesn't have a Q prefix.
as every other header does. Should probably be Qt3DWindow.
2)
Kevin Kofler wrote:
> Koehne Kai wrote:
>> One thing to worry about though is Linux distributions: We certainly
>> don't want to let them stick to an old Qt version because there are
>> applications still depending on qtquick1. However, a quick search with
>> e.g. osc for openSUSE shows that this
Oswald Buddenhagen wrote:
> On Tue, Apr 07, 2015 at 04:59:20PM +0200, Stephen Kelly wrote:
>> Something 'funny' is going on with
>>
>> https://codereview.qt-project.org/#/c/106855/
>>
> apparently, it wasn't properly "tagged" after a ma
Something 'funny' is going on with
https://codereview.qt-project.org/#/c/106855/
See qtbase commits
* 0b6bfe8c448179ccf9272a309d6b9ddbdc055960
* d9437af198726e80d68ae4d95108cb08602d07f9
* 22b5e178e5a32988f8c23170288ef3d48df5f00d
* 558c9cadddacea37669c28ec2abe62c8f5726e8e
* 6dcbaa487d222440
Thiago Macieira wrote:
> Fix what? Until someone says this is a problem, we don't know if it is.
Fair enough.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Thiago Macieira wrote:
> On Tuesday 24 March 2015 19:40:52 Stephen Kelly wrote:
>> Thiago Macieira wrote:
>> > On Tuesday 17 March 2015 09:40:08 Olivier Goffart wrote:
>> >> > Opinions for or against?
>> >>
>> >> I think it's a good
Thiago Macieira wrote:
> On Tuesday 17 March 2015 09:40:08 Olivier Goffart wrote:
>> > Opinions for or against?
>>
>> I think it's a good idea, just like we have QT_USE_QSTRINGBUILDER, we
>> could have QT_CHECK_ASSERT or something like that.
>
> Ok, I'll prepare a patch.
Did this happen?
Thank
Thiago Macieira wrote:
> The reason we prefer -std=c++11 is that it allows us to write code that
> doesn't trip GNU extensions unlikely to be found on MSVC and other
> compilers.
What is the likelyhood of that? No one is going to accidentally add an
`__attribute ((strong))` namespace in Qt.
I
Thiago Macieira wrote:
>
> Anything I missed? Opinions?
As far as I know, qmake `CONFIG += c++11` causes
-std=c++11
or similar to be used on compile and link lines. For the sake of user code,
you might want to use
-std=gnu++11
instead, because
-std=gnu++98
is the default and you turn
Thiago Macieira wrote:
> Because we want to benefit from the new code and remove the unnecessary
> #ifndef and Q_UNUSED. If we don't change the current macro, then we
> deprecate the old one and convert all the code to the new one
You could deprecate the old behavior.
#ifdef QT_BUILDING_QT || QT
Thiago Macieira wrote:
> On Saturday 14 March 2015 18:34:08 Kevin Kofler wrote:
>> Thiago Macieira wrote:
>> > [moving to dev; interest in BCC]
>> >
>> > On Saturday 14 March 2015 16:44:33 René J.V. Bertin wrote:
>> >> I am working on a patch for QStandardPaths and a switch (to toggle
>> >> betwe
Thiago Macieira wrote:
>> What macro works for multiple versions of Qt?
>> Why should everyone define such a macro themselves in their code? How
>> about contributing it back to qglobal.h? What would it be called? And to
>> bring this full circle, how about swapping the semantic of the old and
>>
Thiago Macieira wrote:
> This was intentional and the minor SIC was expected. It only happens if
> you're calling a static function that only exists for Q_ASSERT -- not many
> people do that.
Oops, nobody told Allen:
https://github.com/KDAB/GammaRay/commit/44ac33d970e
I think this affects far
Hello,
After commit ebef2ad1 (Make the empty Q_ASSERT still check its
argument for validity, 2014-09-11), there are two source
incompatibilities compared to Qt 5.4. I understand the message in the
commit.
The following code fails to compile with -DQT_NO_DEBUG:
sic.cpp:10:14: error: use of undecl
Stephen Kelly wrote:
> I also recommend hardcoding the exception for enginio and removing the
> generic '-' solution to prevent such problems in the future.
Exception is needed for webkit too, of course.
Thanks,
Steve.
___
Developm
Hello,
https://qt.gitorious.org/qt/qtwebengine/commit/bef6cc644f176a69a85c68126bd0d7e50ab5757e
causes
https://bugreports.qt-project.org/browse/QTBUG-42073
because it disabled the tests (stupidly) instead of disabling the generation
of cmake files. The commit message also conveys lack of u
Hanspeter Niederstrasser wrote:
> I have not been able to find the code that generates the
> .cmake files to figure out why it is not honoring the file extension
> change.
Here they are:
qtbase/mkspecs/features/create_cmake.prf
qtbase/mkspecs/features/data/cmake/*
Thanks,
Steve.
__
Konstantin Podsvirov wrote:
> Thank you! This is what I need.
>
> I have a Gerrit account (user: kot). But I haven't contributed in Qt code.
> What sequence of actions? What instruction I to read?
>
>> I can also create a patch with boilerplate topics or sections where you
>> can add the informa
Kevin Kofler wrote:
>
> Those _qt5_*_check_file_exists checks look unnecessary to me in the first
> place.
Part of the intention of the way CMake config-packages and IMPORTED targets
work is that if the FooConfig.cmake is present and found, and the Foo
IMPORTED target is present, then you can
Berlin! - https://devdays.kdab.com
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
___
Devel
On Monday, June 30, 2014 08:52:45 Thiago Macieira wrote:
> Em seg 30 jun 2014, às 10:28:28, Stephen Kelly escreveu:
> > Qt minor releases are 6 months apart.
> >
> > How realistic is it to conceive, plan, implement and test a 'new major
> > release' of an en
On Monday, June 30, 2014 08:56:31 Thiago Macieira wrote:
> Em seg 30 jun 2014, às 09:36:39, Stephen Kelly escreveu:
> > > If a module wants to release out-of-schedule, it will need to use an
> > > extra
> > > version number, like 5.4.0.1.
> >
> > And 5.4
Join us at Qt Developer Days 2014 in Berlin! - https://devdays.kdab.com
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-In
On Monday, June 30, 2014 10:15:47 Giuseppe D'Angelo wrote:
> On 30 June 2014 09:50, Stephen Kelly wrote:
> > Does "5.4.0" qualify?
> >
> > How much testing does a 'new major version' need?
>
> But according to that scheme that should the ver
On Monday, June 30, 2014 09:47:18 you wrote:
> On 30 June 2014 09:39, Stephen Kelly wrote:
> > Having a huge difference between 5.4.0 and 5.4.0.1 doesn't seem wise to
> > me.
>
> That was just for the sake of the argument. If one decides to release
> a new major vers
On Friday, June 27, 2014 14:50:39 you wrote:
> Hi,
> It seems that Jocelyn answered most of the questions, but I put my answers
> anyway :-)
>
> On Wednesday 25 of June 2014 15:42:36 Stephen Kelly wrote:
> > (...)
> >
> >> Conclusion 1) Even if a Qt m
27;t exist a month ago in the bleeding
edge (when the last release was made) already knows what is in the out of band
release. They are most likely the one who asked for it.
Having a huge difference between 5.4.0 and 5.4.0.1 doesn't seem wise to me.
Thanks,
--
Join us at Qt Develope
er, like 5.4.0.1.
And 5.4.1.1 and 5.4.2.1 etc.
The time between patch releases is already very short. Even the time between
minor releases is reliably short at 6 months.
Thanks,
--
Join us at Qt Developer Days 2014 in Berlin! - https://devdays.kdab.com
Stephen Kelly | Software Engin
all the issues that you raised, so le me know if there is anything that
> we're overseeing,
Thanks. By addressing the issues raised, you've made me more sure that the
issues are real, and disparate version schemes should not be used.
Thanks,
--
Join us at Qt Developer Days 20
n any brain or wiki page?
Thanks,
--
Join us at Qt Developer Days 2014 in Berlin! - https://devdays.kdab.com
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 Exp
1 - 100 of 552 matches
Mail list logo
