Re: [Development] Nomination of Build System Maintainer(s)

2020-01-16 Thread Kevin Funk via Development 
On Wednesday, 15 January 2020 15:27:29 CET Kai Köhne wrote:
> Hi,
> 
> I'd like to nominate Jörg Bornemann and Alexandru Croitor as joint official
> maintainers of the Build System in qtbase, which is officially unmaintained
> [1].
> 
> Jörg has been doing a lot of work and reviews in qmake and the existing Qt 5
> build system after Ossi was leaving The Qt Company.
> 
> Alexandru is currently organizing the work around the CMake port (Qt 6 build
> system), and also does a large fraction of the work himself.
> 
> I believe that, together, they are the right ones to maintain the build
> system area in both Qt 5 and Qt 6.
> 
> Their individual dashboards:
> 
> Jörg: https://codereview.qt-project.org/dashboard/1000120
> Alexandru: https://codereview.qt-project.org/dashboard/1004184

+1 from me as well, they're both doing a great job!

My kudos to Alexandru esp., for driving the Qt 6 build system efforts!

Regards,
Kevin


> Regards
> 
> Kai
> 
> [1] See https://wiki.qt.io/Maintainers
> 
> --
> Kai Köhne, Director R | The Qt Company
> 
> The Qt Company GmbH, Erich-Thilo-Straße 10, D-12489 Berlin
> Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg,
> HRB 144331 B
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development


-- 
Kevin Funk | kevin.f...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts

smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Updating/changing "default" branch for qtbase repository

2019-09-17 Thread Kevin Funk via Development 
On Monday, 16 September 2019 14:10:51 CEST Lars Knoll wrote:
> On 16 Sep 2019, at 13:26, Albert Astals Cid via Development
> mailto:development@qt-project.org>> wrote:
 
> El dilluns, 16 de setembre de 2019, a les 13:22:22 CEST, Frederik Gladhorn
> va
 escriure:
> On mandag 16. september 2019 12:22:06 CEST Edward Welbourne wrote:
> Albert Astals Cid (16 September 2019 11:33) wrote:
> If i do
> 
>  git clone ssh://myu...@codereview.qt-project.org/qt/qtbase
> 
> I get branch 5.12
> 
> Given that 5.12 is now on cherry-pick mode (AFAIK) would it make more
> sense to default to branch 5.13?
> 
> We have a history of setting a release branch (stable, I think; perhaps
> LTS) as the default branch in our repositories.  This means that anyone
> who mirrors our repositories gets that as their default branch (unless /
> until they update it).  I don't see this as a good choice: getting dev
> on the branches that have it would make more sense.
> 
> IIUC, the rationale for the present practice is that we want to make it
> easier for folk who send us fixes.  I honestly doubt we'd suffer harm by
> having fixes sent to us on dev a bit more often (and other changes, that
> *do* belong on dev, being sent first to another branch would surely
> happen less often); reviewers can surely help the contributor get it
> onto the right branch, if there's a good reason why dev isn't good
> enough.
> 
> ... now, where have I met this discussion recently ?
> I'm quite sure I have, but can't remember where ...
> 
> I also had a chat about this recently and the Gerrit admins in general
> don't
 really fell like constantly changing the default branch, so I'd be
> much in favor of just moving all default branches to dev.
> 
> Same here, i think dev makes sense too, but didn't want to propose
> something
 so radical myself ^_^
> 
> +1 for having it pointing to dev and never changing it again. It’s also more
> in line with most other git repos out there :)

OT: Out of curiosity: Why was "dev" chosen over "master" as main development 
branch in the first place? What's the benefit? This is also something which 
might confuse new contributors easily, as it's not the Git standard 
nomenclature.

If we ever wanted to change that, then now would be the time.

I'm sure this has been answered else where but I can't find a hint of it.

Regards,
Kevin

 
> Cheers,
> Lars
> 
> 
> Cheers,
>  Albert
> 
> 
> In my opinion we should mostly care about the dev branch, since that's
> where
 all future development needs to happen. Moving changes back into
> older releases can of course be important, but that's not what most people
> should have to worry about.
> 
> Cheers,
> Frederik
> 
> Eddy.
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
> 
> 
> --
> Albert Astals Cid |
> albert.astals@kdab.com | Senior
> Software Engineer
 Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - The Qt, C++ and OpenGL Experts
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
> 


-- 
Kevin Funk | kevin.f...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts

smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Oslo, we have a problem [char8_t]

2019-07-08 Thread Kevin Funk via Development 
On Monday, 8 July 2019 09:37:24 CEST Allan Sandfeld Jensen wrote:
> On Samstag, 6. Juli 2019 16:53:13 CEST Mutz, Marc via Development wrote:
> > On 2019-07-06 16:38, Konstantin Tokarev wrote:
> > > 06.07.2019, 17:20, "Mutz, Marc via Development"
> > > 
> > > :
> > >> On 2019-07-06 14:50, Fabian Kosmale wrote:
> > >> [...]
> > >> 
> > >>>   See https://godbolt.org/z/e6OinY for how this would look for a
> > >>>  
> > >>>  trivial function.
> > >> 
> > >> [...]
> > >> 
> > >> Now also handle test(NULL) and extend to binary:
> > >> test2([0, NULL, nullptr, "", u8""], [0, NULL, nullptr, "", u8""])
> > >> 
> > >> This doesn't scale...
> > > 
> > > It can be argued that use of NULL in C++ code is more relict thing and
> > > should not be
> > > supported. It's also much easier to migrate code base from NULL to
> > > nullptr - simple text
> > > replacement is enough.
> > 
> > 0 -> nullptr is just as simple: clang-tidy has a fixit for that.
> 
> Won't work on Qt code. At least no nicely. When I tried cleaning up QtCore I
> found we do something ugly with QFlags where passing a 0 somehow goes over
> pointer. The fix for
> QFlags a(0)
> is
> QFlags a = {}
> 
> or we need to update our hack to not trigger the 0 as pointer constant
> warning.

Sorry for derailing more from the original topic:

But for this case another option would be to extend this particular clang-tidy 
checker to support special replacement rules for certain types. It's 
relatively easy to make clang-tidy checkers configurable.

So in this case one would instruct clang-tidy to replace the arg to the 
constructor call `QFlags(...)` with a '{}' instead of a 'nullptr'.

PS: For others wondering about the details about the "QFlags-hack" accepting 
"0", here are all the details:
  https://phabricator.kde.org/D3987

Regards,
Kevin

> 'Allan
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development


-- 
Kevin Funk | kevin.f...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts

smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Fwd: About CMAKE_MKSPEC, the spec file recorded in Qt5CoreConfigExtrasMkspecDir.cmake and "using any compiler"

2019-02-25 Thread Kevin Funk via Development 
On Monday, 25 February 2019 11:04:31 CET René J.V. Bertin wrote:
> On Monday February 25 2019 10:18:01 Kevin Funk wrote:
> 
> Hi,
> 
> >From my quoted message:
> > >> Now, I think it's not entirely relevant whether or not this particular
> > >> setting is a left-over due to me not trashing the entire Qt build
> > >> directory
> > >> before rebuilding with clang. The fact is that you should be able to
> > >> build
> > >> Qt with one compiler and dependent software with another.
> 
> So you confirm that the path indeed depends on the compiler used during the
> Qt build 

Well, yes. That's what currently happens.

The mkspec used cannot be altered when using CMake afaics.

> (and that my installed copy resulted from rebuilding with clang).
> 
> The question remains though why this path determined at Qt build time and
> not at the dependent's build time.

> After all you use CMake to build some
> dependent instead of Qt itself, and CMake makes it easier to use any
> compiler than QMake.

That makes sense in theory. QMake will switch to a different mkspec when you 
pass `-spec ...` when building an external project. It's impossible to 
instruct CMake to do the same right now, as the mkspec is hardcoded in the 
CMake config files of the Qt install.

Maybe there should be a way to overwrite the mkspec used via a -DQT_MKSPEC 
parameter, with the potential drawback of being able to create a broken 
configuration (cf. a MinGW build against a Qt MSVC install; which can't be 
mixed), but I don't know. Deferring the mkspec from CMAKE_CXX_COMPILER would 
be a potential solution, but again, would require quite a lot of additional 
CMake code I'm afraid. Not something I'd envision to maintain for all the 
different mkspecs we have.

So far we haven't had any reports of this issue, and I'd rather leave that for 
Qt6 times where we need to find a different solution regarding mkspecs when 
building Qt with CMake anyway.

> The differences between GCC and clang tend to be small, but take an MSVC
> build of Qt on MSWin, and then build some KDE project with
> -DCMAKE_CXX_COMPILER=clang++ ; could be more problematic, no?

Yes, that's why this hasn't popped up on the bug tracker so far I think. It's 
again an artificial problem:

- Differences between GCC & Clang are tiny (in fact qplatformdefs.h for both 
of them are almost similar). 

- In the example your mention you'd need to use Clang's clang-cl.exe as 
compiler anyway, which is a drop-in replacement for MSVC's cl.exe and thus 
should accept anything from win32-msvc/qplatformdefs.h anyway.

Regards,
Kevin



> 
> R.


-- 
Kevin Funk | kevin.f...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts

smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Fwd: About CMAKE_MKSPEC, the spec file recorded in Qt5CoreConfigExtrasMkspecDir.cmake and "using any compiler"

2019-02-25 Thread Kevin Funk via Development 
On Monday, 25 February 2019 09:56:42 CET René J.V. Bertin wrote:
> Hi,
> 
> Trying to get an answer to the question below once more.
> In a nutshell: shouldn't the CMAKE_MKSPEC (or some equivalent) be preserved
> in the installed CMake modules such that the correct mkspec directory is
> added to the compiler's header include search path?

Hey,

The header include path is part of the _qt5_corelib_extra_includes CMake var.

See:

% ag -s mkspecs /usr/lib/x86_64-linux-gnu/cmake/Qt5Core/
/usr/lib/x86_64-linux-gnu/cmake/Qt5Core/Qt5CoreConfigExtrasMkspecDir.cmake
2:set(_qt5_corelib_extra_includes "${_qt5Core_install_prefix}/lib/x86_64-
linux-gnu/qt5//mkspecs/linux-g++")

That's what you're looking for, right?


If I instead build Qt5 myself using Clang, I end up with this location in the 
.cmake file:

% ag -s mkspecs lib/cmake
lib/cmake/install/Qt5Core/Qt5CoreConfigExtrasMkspecDir.cmake
2:set(_qt5_corelib_extra_includes "${_qt5Core_install_prefix}/.//mkspecs/
linux-clang")

Looks all fine to me?

Regards,
Kevin

 
> Or should that directory be excluded altogether?
> 
> R.
> 
> ---
> I just noticed something strange in the huge compiler commandlines you tend
> to get while building KDE applications. An application configured to build
> with clang adds qt5/mkspecs/linux-g++-64 to the header include path (with
> -isystem, at that).
> 
> At first I thought this was an error in that my Qt install (5.9.7, FWIW) was
> built with GCC but since a release or two I changed to building Qt with
> clang too.
> 
> Now, I think it's not entirely relevant whether or not this particular
> setting is a left-over due to me not trashing the entire Qt build directory
> before rebuilding with clang. The fact is that you should be able to build
> Qt with one compiler and dependent software with another.
> 
> Am I overlooking an existing way to get the correct mkspec directory added
> to the header search path?
> 
> The source for Qt5CoreConfigExtrasMkspecDir.cmake suggests this is set via
> CMAKE_MKSPEC but that variable is no longer referenced in the installed
> cmake modules (again, in Qt 5.9). So even setting this on the commandline
> doesn't have any effect - but CMake should be able to infer at least the
> most common mkspec dirnames from CMAKE_CXX_COMPILER(_ID) ...
> 
> Thanks,
> R.
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development


-- 
Kevin Funk | kevin.f...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts

smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] CMake Workshop Summary

2019-02-13 Thread Kevin Funk via Development 
On Wednesday, 13 February 2019 15:40:15 CET Tor Arne Vestbø wrote:
> > On 13 Feb 2019, at 14:58, Kevin Funk via Development
> >  wrote:
 
> > make it more difficult for distros to co-install the CMake config files
> > for different Qt versions.
> 
> This sounds like a generally useful feature for distros to have, not just
> for major versions but for minor etc too? 

Hey,

No, I don't think so. The majority of distros will just have one install of a 
major version around, in the "default" prefix.

If I understand you correctly, then you'd like to have something like 
"Qt5.12Config.cmake" around? Would in turn require you to write this in your 
CMakeLists.txt as a user of Qt:
  
  find_package(Qt5.12 ...)

Would look a little heavy one the eye at least, and completely diminishes 
find_package's builtin capability to request a certain version via a 
parameter.

Anyhow, I think we're open to suggestions from distro maintainers, people who 
frequently have to deal with issues in that area to find a suitable solution.

> I guess you’d have to solve it manually today? Installing the package in a
> custom location and point cmake to the location so it can pick up the Qt
> cmake files?

Exactly, there's always the solution of installing Qt into a completely 
separate prefix, e.g. "/opt/qt5.12" -- with the drawback of requiring the user 
to set CMAKE_PREFIX_PATH to let CMake find Qt in the desired prefix.

Regards,
Kevin

 
> Tor Arne 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development


-- 
Kevin Funk | kevin.f...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts

smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] CMake Workshop Summary

2019-02-13 Thread Kevin Funk via Development 
On Wednesday, 13 February 2019 11:22:15 CET Vitaly Fanaskov wrote:
> Hi Simon,
> 
> 
> Thank you for the update.
> 
> 
> It's not clear why you included version to a package name (e.g. Qt5/Qt6).
> With CMake you can pass a version as the second argument, e.g.:
> find_package(Qt 5.12)

Heya,

We in fact implemented it in a way so the actual "package prefix" we use 
(here: "Qt5", "Qt6", or even just "Qt") can be changed by just modifying one 
internal variable.

So, technically that's very easy to do.

The problem is, besides the reasons Simon mentioned, that just using "Qt" as 
the package prefix will make it more difficult for distros to co-install the 
CMake config files for different Qt versions.

Still all up for discussions though. Happy to get more people involved.

Regards,
Kevin


> Perhaps it would be better, what do you think?
> 
> 
> On 2/13/19 10:33 AM, Simon Hausmann wrote:
> Hi,
> 
> On Monday/Tuesday a bunch of us met at KDAB offices in Berlin to accelerate
> the attempt of building Qt with CMake. I'd like to give a brief summary of
> this workshop.
> 
> Who: Jean-Michaël, Liang, Volker, Mikhail, Kevin, me, Tobias, Kai and
> Albert.
> 
> A very early visible artifact was the creation of a wiki page (like all good
> workshops ;-)
> 
> https://wiki.qt.io/CMake_Port
> 
> With such a large group, we were able to make good progress:
> 
> * We were able to fix the artifacts of "make install" in qtbase to allow
> for building an external module (qtsvg) and sample apps. 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) (2) Always use Qt::Core, Qt::Gui, etc. for linkage
> (3) We want to add the "plain" Qt::Core, Qt::Gui, targets also to
> Qt5's cmake support
> 
> * The script to converting .pro files to CMakeLists.txt is becoming
> really good. The goal is to convert all scopes and (source) file names
> correctly. Right now the repo contains incremental conversions with
> hand-edits.
> 
> * We're working on installing the latest cmake (as required) in the
> provisioning setup, so that we can get a building CI as soon as possible.
> 
> * We were able to verify that cross-compilation works well. The main
> challenge is ensuring that third-party libraries that used to be copied in
> src/3rdparty are either installed in the sysroot or can be found outside.
> 
> * We discussed and experimented with different ways of making static
> builds robust. So static builds themselves work already, but what we're
> looking into in particular is an automatic way of propagating Qt internal
> dependencies (such as double-conversion) correctly to the build process of
> the application that is not fragile.
> 
> * We added a lot more plugins and platform support libraries to the
> build process and did many improvements to the finding of external
> libraries.
> 
> 
> Our overall next goal is completing the build on Linux, macOS and Windows,
> cross-compilation, static builds and basic CI build support.
> 
> 
> Simon
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
> 
> 
> --
> Best Regards,
> 
> Fanaskov Vitaly
> Senior Software Engineer
> 
> The Qt Company / Qt Quick and Widgets Team


-- 
Kevin Funk | kevin.f...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts

smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] override keyword on destructors

2018-08-20 Thread Kevin Funk via Development 
On Monday, 20 August 2018 14:08:36 CEST Sérgio Martins via Development wrote:
> Hi,
> 
> 
> Looks like some 'override' keywords crept into a few destructors. This
> is probably because clang-tidy warns about it (and now QtCreator).
> 
> IMO we should avoid it, as it's misleading. Dtors are a special case and
> have completely different semantics. They don't replace their base class
> dtors. They're chained instead.
> 
> This is not 100% consensual, some people like to use it.
> 
> But it's discouraged by the Cpp Core Guidelines [1]; gcc's
> -Wsuggest-override doesn't suggest it for dtors and neither does clang's
> -Winconsistent-missing-override.

Heya,

Just as a side note: There's still a warning which will warn for inconsistent 
overrides on destructors in Clang:
  https://www.mail-archive.com/cfe-commits@lists.llvm.org/msg50989.html

(off by default though, it was noted it's too noisy for existing code bases)


To be honest, I find the explanation on the Cpp Core Guidelines wiki pretty 
poor, if not to say non-existent. If you read through the discussion of 
amending of rule C.128 [1] it becomes pretty clear there's no consensus at 
all, but rather one person (gdr-at-ms) trying to push through his preference 
and shutting down the discussion.

I think the destructors-are-chained argument is a bit weak; to me 'override' 
rather translates to "I expect there to exist a base class version of this 
function which is declared virtual" (also cf. [2]), which applies very well to 
destructors. IMO, it would also be nice to get a compiler warning/error if a 
base class' destructor is changed from virtual to non-virtual which may cause 
subtle behavioral changes such as memory leaks.

[1] https://github.com/isocpp/CppCoreGuidelines/issues/721
[2] https://en.cppreference.com/w/cpp/language/override


My 2 cents.

Regards,
Kevin


> So clang-tidy is the one odd out.
> 
> I'll update the coding conventions if nobody opposes.
> 
> 
> 
> [1] -
> https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md
> #Rh-override
> 
> Regards,


-- 
Kevin Funk | kevin.f...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts

smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development