[Interest] qmake: questions regarding huge projects

[Bo Thorsen]

Den 22-04-2013 19:22, Konrad Rosenbaum skrev:
> On Friday 19 April 2013 13:36:36 Bo Thorsen wrote:
>> Den 19-04-2013 12:29, Rainer Wiesenfarth skrev:
>>> well, I know about cmake, but was going for something less cryptic... :-)
>>>
>>> We have some fancy build stuff (f2c, versioning, ...), but I was hoping
>>> to get it done with qmake, _because_ it is simple.
>>
>> I know, but when you have a complicated build process, a simple tool
>> just doesn't cut it.
>
> Let's correct that a little: simple stuff is very simple with qmake,
> complicated stuff is very complicated with qmake, but not impossible.
>
> You can introduce new compilers and generators as well as complex internal
> dependencies, but it takes quite a bit of experience to do so.
>
> The one thing that qmake does not do well is looking for external tools -
> among Linuxers known as the "configure step". So if I have to scan for non-Qt
> dependencies that are not part of my own build-tree, then I employ an
> additional script to search for them and output a .pri file that is re-used in
> the project files for qmake.
>
> Qmake has some severe limitations:
>
> + it can handle all of Qt out of the box
> + you can formulate project internal dependencies (beware the syntax!)
> + you can share configurations if you put them in .pri files
> + you can add simple compilers (1 source file -> 1 destination file)

There's at least one more that's pretty huge on my plus list if we're 
comparing with cmake: *Much* better QtCreator integration. It's so much 
better that I occasionally consider going back to Visual Studio for 
cmake projects.

> - more complex generators are not possible, like
>   -- m source files n destination files

If you have two target output files, this is possible (like .cpp and .h 
output). But if the output files are read from the input file, you are 
correct that there's no way to do it.

Since I absolutely love building code generators for handling stuff like 
REST API calls, DB code and more, this is usually the point where I am 
forced to switch from qmake to cmake.

>   -- if you do not know the destination file names yet
> - searching for external dependencies is not possible
>   -- if you know you need Python, but have to search for the version: forget it

On Windows, the Python libs have the version number in the name. I've 
hit this limitation as well. It's of course the same for all other libs 
with versions.

> - if shell commands for an action differ per OS, the statements become
>    exponentially more complex or you have to write something in another
>    language (e.g. Perl, Python, C++, ...)

And on Windows, you have no scripting. Cmake at least offers some of 
what you might want to do with a script.

> - scanning for features before building the Makefile is not possible (e.g. if
>    you have to find out whether you have memcpy or bcopy)
>
> So if you have to do any of the "impossible" tasks you have to put them before
> the qmake run and generate include files for the qmake project - just like the
> configure script for Qt itself.
>
> If you can live with this then qmake is a very good tool for you. For example
> I've been known to put the "impossible" stuff into Tcl scripts for a project
> that needs a Tcl environment anyway.

I have often considered creating a qmake patch to really support code 
generators, because this is the biggest chunk of "impossible". But with 
QBS coming, is it actually worth it? The bad thing about QBS is that 
qmake feels like a dead end now, but I still see some risk that QBS is 
never finished. Am I wrong in this?

Bo.

-- 
Bo Thorsen, European Qt Manager, Integrated Computer Solutions
ICS - Delivering World-Class Applications for Embedded & Mobile Devices
http://ics.com/services