Announcement

Collapse
No announcement yet.

What Build System Should Qt 6 Use?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • brrrrttttt
    replied
    Originally posted by kpedersen View Post
    Unfortunately it will be quite hard to take advantage of Qt as a GUI system without inheriting from its base object (QObject)

    Another solution to Moc would be to use the Qt 4 fork (http://www.copperspice.com/) who have replaced the crap code that relies on it.
    That Copperspice stuff is truly awful. Verdigris is nice, but more of a pain than MOC, which just stays out of your way and does it's job.

    Leave a comment:


  • patstew
    replied
    Originally posted by kpedersen View Post
    Unfortunately it will be quite hard to take advantage of Qt as a GUI system without inheriting from its base object (QObject)

    Another solution to Moc would be to use the Qt 4 fork (http://www.copperspice.com/) who have replaced the crap code that relies on it.
    You can use the built in GUI components without inheriting QObject, which will probably get you quite far in many cases.
    You can use Verdigris as Nth_man suggested which gives you copperspice-style ugly macros to replace moc, but unlike copperspice it's just a header that works with regular Qt 5.
    Or you can just use moc. A simple program that generates an extra .cpp file with some boilerplate isn't that hard to add to a build system. It doesn't preprocess or modify your code as lots of anti-moc people seem to think it does.

    On the original point, I wish they'd just use CMake. The syntax isn't perfect, but it's the most full-featured build system and it's the closest thing to a standard build system in the C++ world.
    Last edited by patstew; 26 July 2018, 05:57 PM.

    Leave a comment:


  • Nth_man
    replied
    > that it will guarantee that a Qt 4 project is actually build-able in 20 years time

    As Kervala wrote: "Qt API existing since Qt 1.0 didn’t change much, I know a lot of libraries that had huge changes even in minor versions (like OpenSSL from 1.0.2 to 1.1.0). I enjoyed reading http://blog.qt.io/blog/2018/05/24/porting-from-qt-1-0/ , perhaps you'll like it, too :-)

    Leave a comment:


  • Nth_man
    replied
    Yes.

    > It is a GUI library... not an OS.

    Qt includes QtWebengine, which is very, very useful, but also makes Qt requirements complex; modern browsers are like operating systems :-O

    On the other hand, it reminded me of Qt Lite project — Qt for any size:
    - https://blog.basyskom.com/2017/qt-lite/
    - http://blog.qt.io/blog/2017/05/31/qt-lite-qt-5-9-lts/
    - http://blog.qt.io/blog/2016/08/18/in...hing-any-size/

    Leave a comment:


  • kpedersen
    replied
    Unfortunately it will be quite hard to take advantage of Qt as a GUI system without inheriting from its base object (QObject)

    Another solution to Moc would be to use the Qt 4 fork (http://www.copperspice.com/) who have replaced the crap code that relies on it.

    Leave a comment:


  • Nth_man
    replied
    > basically... Get rid of that MOC shit.

    This information is partially fetched from <https://www.angrycane.com.br/en/2018/06/21/the-day-kate-gregory-enjoyed-qt/>:

    You can create complete Qt applications without the Meta-Object Compiler (moc):

    - You don’t need to use moc-like code if you don’t inherit from QObject.

    - If you inherit from QObject: you need to use moc-like code, but that can be done with:
    * moc (easiest way);
    * hand written if you feel like it (but why?);
    * [Verdigris](https://woboq.com/blog/verdigris-qt-without-moc.html).

    You can create something that’s unrelated to a widget, you can use QtNetwork, QtXML, threads (http://doc.qt.io/qt-5/qtconcurrent-index.html), and more that you can find in http://doc.qt.io/qt-5/qtmodules.html
    Last edited by Nth_man; 26 July 2018, 04:27 AM.

    Leave a comment:


  • kpedersen
    replied
    Can they perhaps just simplify Qt enough that any build system is easy to fit. Something so I can just do:

    $ c++ `find -name '*.cpp'`

    and it just does a full compile. Then I can hook it up to our internal build systems that does the dependency tracking.

    basically... Get rid of that MOC shit. Cut out the pointless superfluous dependencies and just write the whole system correctly so that it will guarantee that a Qt 4 project is actually build-able in 20 years time

    It is a GUI library... not an OS. Why is it so sloppy?

    Leave a comment:


  • JoeTennies
    replied
    I worked on a commercial project that used Qt for the GUI. My team was in charge of switching it from Motif to Qt 4 (Qt5.x was out at the time). We started by using qmake. qmake had some functionality that meant that we couldn't use it at all. I think it had something to do with generating multiple outputs. Anyways, we eventually switched to CMake, and it did what we needed. That stated, I don't think anyone really knew how to maintain the file after the first person left. It was a "necessary evil" to complete the job.

    Now, I do a lot more C than C++, but there's a lot of people I've heard say good things about switching to Meson. The GTK+/GNOME people are switching in droves. MESA is switching. Xorg is switching. I've actually heard about people liking Meson.

    So, I'd say CMake is the safe pick. It can definitely do whatever Qt needs. CMake is likely the best pick today. We're talking about 2 years from now. Spend some effort right now, and Meson might be what you need. If you aren't going to put time into the build system (which is a fair decision), then choose CMake. I'm unsure why anything else other than just not changing is being considered.

    Leave a comment:


  • brrrrttttt
    replied
    Originally posted by johanb View Post

    Fair enough, but it is still don't see this as something critical.
    It's good convention to split your build for each architecture/toolchain into separate build directories and you rarely have to modify your cross file once it's correctly set up.
    It's a great way to have weird behaviour that's only reproducible for a subset of developers (e.g. arch specific FPU flag changed). That's exactly the worst type of bug.

    Leave a comment:


  • Nth_man
    replied
    As it was already written:

    > Why a new build system and not CMake?

    When not using CMake on a daily basis, you will likely forget everything very soon. Not so with Qbs.
    Qbs uses a very elegant and easy-to-remember declarative DSL (QML) where users can focus on WHAT they want to build rather than HOW. That’s really an innovation.

    Leave a comment:

Working...
X