3 ms·
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 Incredi
by 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 agoMy 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 agoTry 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 agoI agree on the using some other language to do builds instead of using a complicated build process. Python is sufficient enough for me.