Creator Qmake-enhancements with containerised toolchain

Containerised dev host toolchain is the official solution for Mac as well as Windows on ARM. Qmake was identified earlier as a key required feature for a usable containerised toolchain product also. However there are issues remainign on the Qmake-support:

-It works for simple things ("simple" as in "c++ hello world") but to make it usable for real world projects we would need either proper work on qmake itself (e.g. to make it create output like cmake's 'fileapi' when run on the device) or, at the very least as a workaround, on the way how mkspecs/modules*.pri are parsed.

This ticket tracks the work item of providing sufficient support for Qmake, work estimate would be some weeks.

​

The company focus is on Cmake but Qmake can still be used for app development and based on queries to presales Qmake usage was still on high levels on embedded.

One big issue is the amount of .prf files read by qmake in principle (e.g. also for qt modules that are not used at all), as with the current access this is funneled via creator's remote access into creator and processed there. system calls in this context are then triggered from creator in the container, output funneled back. a possible solution would be a system like cmake's FileApi, provided by qmake, so qmake is effectively called just once, and all the work is done from qmake-in-the-container's point "locally" (in the container). handling that on the creator side would follow the same pattern as the cmake file API access which is roughly 1500 LOC total. what this would take on the qmake side is so far unclear.