Allow controlling qmake build per configuration

We on the Carbide team have had several requests which require that qmake be run in a different way based on the active build configuration. See the email attachment.

(When a Symbian project is created, it can have a plethora of build configurations, where several Symbian SDKs may each have unique variants of the Qt SDK installed. Thus, there is no global QMAKESPEC or qmake to invoke. Indeed, in the recent 10.1 MCL, we must invoke "qmake.bat" instead of "qmake.exe".)

I fully understand it is a big effort to revamp the entire builder to deal with build configurations (e.g. QTBUG-4326, QTBUG-2805, QTBUG-3432, as well as QTBUG-5931.). But that isn't what I'm asking for here, though it will be a basis for such support.

As an interim solution, may I suggest that you either (a) extend the Qt Makefile Builder so it can be controlled by another builder, or (b) let the Qt Makefile Builder override its build parameters from parameters set inside a CDT build configuration?

Specifically, we need (1) to select a specific Qt version for different build configurations, (2) a way to explicitly specify QMAKESPEC per build configuration, and (3) a way to set EPOCROOT if needed. (The last one is an SBSv2 requirement; EPOCROOT may be set in the system environment, but we need to override it per configuration.)

Currently, we call QMakeRunner#runQMake when we create a Qt Symbian project, and we can pass "Map<String,String> envMods" and mostly achieve all three things above, except (1). BUT, after that point, we have no control at all anymore, since the Qt Makefile Builder is a distinct builder which is run by Eclipse. We can't pass configuration-specific parameters when an automatic or manual build occurs later.

If you implemented (a), then Carbide could invoke some QtProject() method that says "never build on your own". (This is distinct from #setRunQMakeWhenProFileChanges(), because the user can explicitly call Project > Build Project and invoke your builder.) In this case, Carbide would invoke QMakeRunner on its own, passing "envMods". We'd still need to change the Qt version on every build, which seems like a hack. So adding a parameter where we could control the Qt version used, would also be useful.

If you implemented (b), I'm imaginging the Qt Makefile Builder would expose named configuration data storage (via ICConfigurationDescription / ICStorageElement) where qmake build parameters could be fetched to control the Qt version, QMAKESPEC, and other environment modifications. (If not present, the global project settings would be used.) This would allow Carbide to set such parameters at project creation or build configuration creation time and achieve the same result as above, without also taking ownership of when to invoke your builder. It would be the preferred solution

(Note that CDT build configurations and the storage mechanism mentioned above work the same in any CDT project, no matter which Eclipse product created the project. Thus, it wouldn't require any outward support for build configurations in the Qt Eclipse Integration yet.)