5 ms·

Thanks for supporting CMake and deprecating qmake. Not that cmake is the best tool ever, but having to deal with several build systems in the same project has a

by jupp0r 7y ago

Thanks for supporting CMake and deprecating qmake. Not that cmake is the best tool ever, but having to deal with several build systems in the same project has always been a nightmare.

dgellow 7y ago
Oh yes, finally! That's such a good news! Learning, using, maintaining a qmake + cmake build setup for various platforms is really a pain in my (limited) experience.
rumanator 7y ago
It should also be noted that the folks working on Qt Creator have pending issues to add support for other build systems.
halflings 7y ago
Would have hoped they would use bazel instead. It's open-source, and so much easier to deal with than CMake.
- 4ad 7y ago
  Are you kidding me, bazel is written in Java...
  - malkia 7y ago
    so what? Bazel spawns a server, the next invocation is really fast.
    - tonyarkles 7y ago
      You’re not helping your case! Spawning a server (a JVM-based one at that!) to be able to get reasonably performant builds is horrifying! As a simple example, I hack on a Qt app on a Raspberry Pi (it has a tiny display on it and I run a dashboard). It’s only got 512MB of RAM and spinning up a JVM server to run my builds will likely cause it to run out of RAM. I’m not the world’s biggest fan of CMake, but it sure solves a lot of problems while being quite lightweight. And I’ll take it over qmake, mostly because I know CMake well enough and haven’t ever really gotten into the guts of qmake. CMake is more general purpose.
      - wwright 7y ago
        Bazel’s approach is to cross compile from a stronger platform
        pjmlp 7y ago
        So it not only requires a daemon, it also depends on additional hardware.
        wwright 7y ago
        It doesn’t depend on additional hardware, but it’s designed to make it very easy to cross compile. The internal Google tool it’s built on also has strong support for sharing build servers between devs, and they want to enable that in the open source version. It also doesn’t require a daemon: you can ask it not to do that, so the biggest cost is a JVM warmup. That said, these are really moot concerns: for almost any project where engineering is involved, the cost of having an engineer in the first place significantly outweighs the costs of having as many hefty CPUs as you really need for build. If you can’t get a decent i7 for a build node, there’s probably a lot more things limiting you, too.
      - malkia 7y ago
        I don't get why are you saying it's horrifying. It keeps cached copy of the build graph, among other things, so subsequent invocations of the build systems, there is less to read cold again. It's pretty good design. Also the server dies after some time (controlled by some default). MOC/UIC/RCC would've integrated much easier there, than what's right now.
        tonyarkles 7y ago
        How much memory does that take, vs something like CMake that starts cold? I can see why you'd want to do that if you have an absolutely massive dependency graph for your build, but outside of a few select companies, that's probably not the case.
  - cerberusss 7y ago
    I instantly understand what you're saying. I wouldn't want that in my build process either.
- malkia 7y ago
  Me too. I love bazel, for the plain syntax, sandwiches (deps between languages), determinism, just plain good stuff. I use it for all my new personal projects (linux/windows).
- wokwokwok 7y ago
  No one loves CMake and it’s custom scripting language. It’s selling point is that it works, and it does. Its a pragmatic choice. I think this is one of those “join the crowd” things at this point. Picking CMake for QT is a great decision. ...for personal projects, by all means take your pick, but bazel wasn’t ever really a contender in this space for them.
- slavik81 7y ago
  They've been working on the transition from QMake to CMake since 2012 (or earlier). It was a topic at the Qt Developer Days when they released Qt5, long before Bazel was an option.
hawski 7y ago
I hope that in future the module system that will be introduced by C++20 will eventually kill CMake. Having said that I don't know the scope of the functionality brought by it, but if not with C++20 the next one will probably be good enough. I wonder what's the Qt 6 road-map as C++20 is around the corner and is supposed to bring an amount of change similar to Qt 6, I presume. But basing on C++17 is already as new as it gets with their client base in embedded sector for example. Though it may be a bit too new. They can't lay dormant so it's a good deed after all, although timing seems unfortunate.
- jcelerier 7y ago
  > I hope that in future the module system that will be introduced by C++20 will eventually kill CMake. To the contrary - with modules more powerful build systems are needed that the ones which exist today. See this post for a CMake dev : https://www.reddit.com/r/cpp/comments/axnwiz/cmake_gcc_module_proofofconcept/ https://www.reddit.com/r/cpp/comments/axnwiz/cmake_gcc_modul...

by jupp0r 7y ago

Thanks for supporting CMake and deprecating qmake. Not that cmake is the best tool ever, but having to deal with several build systems in the same project has always been a nightmare.

dgellow 7y ago

Oh yes, finally! That's such a good news! Learning, using, maintaining a qmake + cmake build setup for various platforms is really a pain in my (limited) experience.

rumanator 7y ago

It should also be noted that the folks working on Qt Creator have pending issues to add support for other build systems.

halflings 7y ago

Would have hoped they would use bazel instead. It's open-source, and so much easier to deal with than CMake.

4ad 7y ago
Are you kidding me, bazel is written in Java...
- malkia 7y ago
  so what? Bazel spawns a server, the next invocation is really fast.
  - tonyarkles 7y ago
    You’re not helping your case! Spawning a server (a JVM-based one at that!) to be able to get reasonably performant builds is horrifying! As a simple example, I hack on a Qt app on a Raspberry Pi (it has a tiny display on it and I run a dashboard). It’s only got 512MB of RAM and spinning up a JVM server to run my builds will likely cause it to run out of RAM. I’m not the world’s biggest fan of CMake, but it sure solves a lot of problems while being quite lightweight. And I’ll take it over qmake, mostly because I know CMake well enough and haven’t ever really gotten into the guts of qmake. CMake is more general purpose.
    - wwright 7y ago
      Bazel’s approach is to cross compile from a stronger platform
      - pjmlp 7y ago
        So it not only requires a daemon, it also depends on additional hardware.
        wwright 7y ago
        It doesn’t depend on additional hardware, but it’s designed to make it very easy to cross compile. The internal Google tool it’s built on also has strong support for sharing build servers between devs, and they want to enable that in the open source version. It also doesn’t require a daemon: you can ask it not to do that, so the biggest cost is a JVM warmup. That said, these are really moot concerns: for almost any project where engineering is involved, the cost of having an engineer in the first place significantly outweighs the costs of having as many hefty CPUs as you really need for build. If you can’t get a decent i7 for a build node, there’s probably a lot more things limiting you, too.
    - malkia 7y ago
      I don't get why are you saying it's horrifying. It keeps cached copy of the build graph, among other things, so subsequent invocations of the build systems, there is less to read cold again. It's pretty good design. Also the server dies after some time (controlled by some default). MOC/UIC/RCC would've integrated much easier there, than what's right now.
      - tonyarkles 7y ago
        How much memory does that take, vs something like CMake that starts cold? I can see why you'd want to do that if you have an absolutely massive dependency graph for your build, but outside of a few select companies, that's probably not the case.
- cerberusss 7y ago
  I instantly understand what you're saying. I wouldn't want that in my build process either.
malkia 7y ago
Me too. I love bazel, for the plain syntax, sandwiches (deps between languages), determinism, just plain good stuff. I use it for all my new personal projects (linux/windows).
wokwokwok 7y ago
No one loves CMake and it’s custom scripting language. It’s selling point is that it works, and it does. Its a pragmatic choice. I think this is one of those “join the crowd” things at this point. Picking CMake for QT is a great decision. ...for personal projects, by all means take your pick, but bazel wasn’t ever really a contender in this space for them.
slavik81 7y ago
They've been working on the transition from QMake to CMake since 2012 (or earlier). It was a topic at the Qt Developer Days when they released Qt5, long before Bazel was an option.

hawski 7y ago

I hope that in future the module system that will be introduced by C++20 will eventually kill CMake. Having said that I don't know the scope of the functionality brought by it, but if not with C++20 the next one will probably be good enough. I wonder what's the Qt 6 road-map as C++20 is around the corner and is supposed to bring an amount of change similar to Qt 6, I presume. But basing on C++17 is already as new as it gets with their client base in embedded sector for example. Though it may be a bit too new. They can't lay dormant so it's a good deed after all, although timing seems unfortunate.

jcelerier 7y ago
> I hope that in future the module system that will be introduced by C++20 will eventually kill CMake. To the contrary - with modules more powerful build systems are needed that the ones which exist today. See this post for a CMake dev : https://www.reddit.com/r/cpp/comments/axnwiz/cmake_gcc_module_proofofconcept/ https://www.reddit.com/r/cpp/comments/axnwiz/cmake_gcc_modul...