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
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
> -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:
> >
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 point.
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,
> 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'
> 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
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
;
>
> 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
> 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
> 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.
> 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 <stke...@microsoft.com>
> Cc: Jean-Michaël Celerier <jeanmichael.celer...@gmail.com>;
> developmen
[mailto:doom.ooseve...@gmail.com] On Behalf Of
Jean-Michaël Celerier
Sent: Thursday 21 September 2017 11:29
To: Stephen Kelly <stke...@microsoft.com>
Cc: development@qt-project.org
Subject: Re: [Development] New approach to hi-dpi and coordinate system for
layouts in Qt 6
> making it impossible t
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
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
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.
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.
I'm having
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 also means
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 anything though
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
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
>&g
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:
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:
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:
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
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:
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:
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
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
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 the Qt
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
-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
<development@qt-project.org <mailto:development@qt-project.org>>:
This can also b
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
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
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
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
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
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 00:45, Andrew den Exter wrote:
On Thu, Jan 21, 2016 at 2:11 AM, Stephen Kelly
<stephen.ke...@ableton.com <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
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 Allee 6-7, 10119 Berli
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,
On 20/01/16 01:23, Andrew den Exter wrote:
On Wed, Jan 20, 2016 at 2:13 AM, Stephen Kelly
<stephen.ke...@ableton.com <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
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
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
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
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
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 mailing
Hello,
Using this testcase:
#include QCoreApplication
#include QTimer
#include QDebug
int main(int argv, char **args)
{
QCoreApplication app(argv, args);
qDebug() QCoreApplication::instance() qApp;
QTimer::singleShot(0, qApp, SLOT(quit()));
return app.exec();
}
and
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
On Thu, Jun 11, 2015 at 11:49 AM, Marc Mutz marc.m...@kdab.com 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.
I think you come
On Thu, Jun 11, 2015 at 12:29 PM, Marc Mutz marc.m...@kdab.com 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
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 any of the questions I asked
here:
http
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 new.
Whatever you rebutted was not my claim.
So, you believe
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.
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 temporary putting in
place in the examples for now.
I'll try to tidy up
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 existing
On Tue, Jun 9, 2015 at 11:01 AM, Sean Harmer sean.har...@kdab.com 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
qaspectjobmanager.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)
Something 'funny' is going on with
https://codereview.qt-project.org/#/c/106855/
See qtbase commits
* 0b6bfe8c448179ccf9272a309d6b9ddbdc055960
* d9437af198726e80d68ae4d95108cb08602d07f9
* 22b5e178e5a32988f8c23170288ef3d48df5f00d
* 558c9cadddacea37669c28ec2abe62c8f5726e8e
*
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 manual fixup.
i hacked the database now.
Great, thanks.
everybody
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.
In
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?
Thanks,
Steve.
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 idea, just like we have QT_USE_QSTRINGBUILDER, we
could have QT_CHECK_ASSERT
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:
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
new
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
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
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.
___
Development mailing list
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.
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
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 information.
On Friday, June 27, 2014 09:34:19 Thiago Macieira wrote:
Em sex 27 jun 2014, às 10:57:14, Stephen Kelly escreveu:
I guess this is a subject for when and if the situation happens again.
Make that suggestion next time too.
The enginio situation happened because it was not actually
even if
they use the same configuration.
These seem to be arguments in favor of not using a disparate version scheme.
Can you say why you need a disparate version scheme?
Thanks,
--
Join us at Qt Developer Days 2014 in Berlin! - https://devdays.kdab.com
Stephen Kelly stephen.ke...@kdab.com
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 2014 in Berlin! - https://devdays.kdab.com
Stephen Kelly stephen.ke...@kdab.com | Software
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 stephen.ke...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH Co.KG, a KDAB Group
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 Developer Days 2014 in Berlin! - https://devdays.kdab.com
Stephen
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 module has a disparate version scheme, bumping
its
On Monday, June 30, 2014 10:15:47 Giuseppe D'Angelo wrote:
On 30 June 2014 09:50, Stephen Kelly stephen.ke...@kdab.com wrote:
Does 5.4.0 qualify?
How much testing does a 'new major version' need?
But according to that scheme that should the version number used when
linking against
in Berlin! - https://devdays.kdab.com
Stephen Kelly stephen.ke...@kdab.com | 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
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.1.1 and 5.4.2.1 etc.
Why?
Let's take an example
On Thursday, June 26, 2014 08:38:01 Thiago Macieira wrote:
Em qui 26 jun 2014, às 09:52:20, Stephen Kelly escreveu:
Therefore
the
major version must stay the same until Qt 6.
Why is it not acceptable?
Because Lars did not accept it.
Well, the solution
On Wednesday, June 25, 2014 09:32:15 Thiago Macieira wrote:
Em qua 25 jun 2014, às 17:57:35, Stephen Kelly escreveu:
On Wednesday, June 25, 2014 08:04:31 Thiago Macieira wrote:
Em qua 25 jun 2014, às 15:42:36, Stephen Kelly escreveu:
This is of course the same situation that could arise
, not to force every library version to 5.
We agreed...
I am making proposals to agree on.
Thanks,
--
Join us at Qt Developer Days 2014 in Berlin! - https://devdays.kdab.com
Stephen Kelly stephen.ke...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company
Stephen Kelly stephen.ke...@kdab.com | 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
On Monday, May 26, 2014 20:54:51 Stephen Kelly wrote:
Hello,
This tweet was brought to my attention:
https://twitter.com/Korchkidu/status/470850176366968832
Hello,
I discussed with Ossi a way to prevent this in the future.
The create_cmake.prf file now searches for cmake unit tests
it is a 'past mistake'.
Thanks,
--
Join us at Qt Developer Days 2014 in Berlin! - https://devdays.kdab.com
Stephen Kelly stephen.ke...@kdab.com | 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
On Wednesday, June 25, 2014 08:04:31 Thiago Macieira wrote:
Em qua 25 jun 2014, às 15:42:36, Stephen Kelly escreveu:
This is of course the same situation that could arise if linking a program
with both Qt4Core and Qt5Core or anything. The problem is that we have
this
problem within
://devdays.kdab.com
Stephen Kelly stephen.ke...@kdab.com | 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
that they can be named anything?
Thanks,
--
Join us at Qt Developer Days 2014 in Berlin! - https://devdays.kdab.com
Stephen Kelly stephen.ke...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB
be 'fixed' by bumping the major version number, fixing the
library name and the include directory name.
What do you think?
Thanks,
--
Join us at Qt Developer Days 2014 in Berlin! - https://devdays.kdab.com
Stephen Kelly stephen.ke...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH Co.KG
2014 in Berlin! - https://devdays.kdab.com
Stephen Kelly stephen.ke...@kdab.com | 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
1 - 100 of 437 matches
Mail list logo
