4 ms·

Currently I'm doing C++ with Qt, sometimes C# (game dev under Windows), but was at Google just few months ago doing Java. While Qt is great, we've been running

by malkia 9y ago

Currently I'm doing C++ with Qt, sometimes C# (game dev under Windows), but was at Google just few months ago doing Java. While Qt is great, we've been running into logistic problems - like we have plenty of tools that use it, and we are forced to place all the binaries into one folder ("bin"), and the Qt dlls there for legal reasons, license, but buying the license for static linking won't be a problem for us reallly. The real problem is that once we link our binaries statically, then our plugins that also use Qt won't work with them, unless we do some magic, and forward all QtXxx.dll end points to be from the main executable, or use more abstract interfaces - e.g. our plugins should not use Qt directly.

kodablah 9y ago
I likewise have used these. Qt (really C++) development in general suffers from annoyingly slow compile times in my experience. Also, once you go beyond anything trivial, .pro files become complicated as do build systems around them.
- malkia 9y ago
  We don't use .pro files or QtCreator - it's Visual Studio + custom build rules. Still slow, and nasty with generation. As build system, we used to have IncrediBuild, but since we are PS4 developers we get SN-DBS for free - http://www.snsys.com/products/SN-DBS.asp http://www.snsys.com/products/SN-DBS.asp - it speeds up the build, but once the Qt moc/etc rules come in, the build needs to wait for these to be generated, and then proceeds. There are ways to overcome this, and we are looking into improving this. I've tried using .pro files, but first, I can't sell them to the rest of the engineers, as pretty much almost everyone knows Visual Studio, .sln/.vcxproj files. There are some ideas about alternative build systems, but not there yet. (at the end most of these just generate .sln/.vcxproj, like CMake, or premake, etc.).
  - kodablah 9y ago
    My application is cross platform. So I use .pro files + qmake, then make/nmake. As I started needing to move files around in cross platform ways, I just maintain a Go script now that does the build. Tired of custom DSLs and having to dig deep into build-system-specific things (e.g. Groovy w/ Gradle and the confusion around what code runs when like defs vs tasks, doFirst, etc).
    - malkia 9y ago
      Try using "jom" as replacement for nmake - it's done by Qt themselves, and it's much better! - https://wiki.qt.io/Jom https://wiki.qt.io/Jom
    - ateesdalejr 9y ago
      I agree on the using some other language to do builds instead of using a complicated build process. Python is sufficient enough for me.
zura 9y ago
Why do you need to link statically?
jcelerier 9y ago
> but buying the license for static linking won't be a problem for us reallly. You can statically link with LGPL code, as long as you provide a means to relink (typically, shipping .o files if requested). https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami...

by malkia 9y ago

kodablah 9y ago

I likewise have used these. Qt (really C++) development in general suffers from annoyingly slow compile times in my experience. Also, once you go beyond anything trivial, .pro files become complicated as do build systems around them.

malkia 9y ago
We don't use .pro files or QtCreator - it's Visual Studio + custom build rules. Still slow, and nasty with generation. As build system, we used to have IncrediBuild, but since we are PS4 developers we get SN-DBS for free - http://www.snsys.com/products/SN-DBS.asp http://www.snsys.com/products/SN-DBS.asp - it speeds up the build, but once the Qt moc/etc rules come in, the build needs to wait for these to be generated, and then proceeds. There are ways to overcome this, and we are looking into improving this. I've tried using .pro files, but first, I can't sell them to the rest of the engineers, as pretty much almost everyone knows Visual Studio, .sln/.vcxproj files. There are some ideas about alternative build systems, but not there yet. (at the end most of these just generate .sln/.vcxproj, like CMake, or premake, etc.).
- kodablah 9y ago
  My application is cross platform. So I use .pro files + qmake, then make/nmake. As I started needing to move files around in cross platform ways, I just maintain a Go script now that does the build. Tired of custom DSLs and having to dig deep into build-system-specific things (e.g. Groovy w/ Gradle and the confusion around what code runs when like defs vs tasks, doFirst, etc).
  - malkia 9y ago
    Try using "jom" as replacement for nmake - it's done by Qt themselves, and it's much better! - https://wiki.qt.io/Jom https://wiki.qt.io/Jom
  - ateesdalejr 9y ago
    I agree on the using some other language to do builds instead of using a complicated build process. Python is sufficient enough for me.

zura 9y ago

Why do you need to link statically?

jcelerier 9y ago

> but buying the license for static linking won't be a problem for us reallly. You can statically link with LGPL code, as long as you provide a means to relink (typically, shipping .o files if requested). https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami...