Allow custom arguments for module builds

Background

Some items which are set up in provisioning scripts need additional options set when running qmake and tests.

In this specific case we install a library dependency for the Qt OpcUA module. The path of the install location has to be passed to qmake in order to find it. For this purpose there is a variable which qmake understands and the qmake call should be

qmake -- OPEN62541_PREFIX=/path/to/install/location

Previous Investigation

Initially the idea was to add a QtOpcUAModule in modules.py of tqtc-coin-ci. However, QMakeModule does not provide any mean to specify additional arguments when invoking qmake (see modules.py line 267). Even if that was possible, it requires to have two changes to add a backend to a module, one for the provisioning and one additional one for coin itself.

Suggested Solution

The idea is to be able to specify arguments for various build steps inside the provisioning scripts, or rather have an “instruction” file co-located within provisioning. COIN has to store the file after provisioning is done and apply/execute the settings from that file when running qmake or the tests.

Both solutions need to support setting additional options to be prepended to qmake call and prepending the PATH or LD_LIBRARY_PATH when running the tests. (Further options may be added in future releases)

Coin would then load this instruction file before building and testing a module, set its configuration accordingly and invoke QMakeModule functions. This leads to a much cleaner module.py. The instruction file could be created in multiple ways. Discussions here lead to two options:

1. Json

{
    “qt/qtopcua”: [
        [ {“compiler”:”msvc2015”, “arch”:”x86”},
          {“qmake”: “OPEN62541_PREFIX=xyz”, “PATH”:”xyz/bin”}
        ]
    }
}

2. Python

def configure(config: TestConfiguration) -> dict(str,str):

This will do the same as the JSON before but calls a python function inside this file which return a dict instead.

The python option has multiple advantages:

1. It allows to keep the same syntax/variables as being used inside tqtc-coin-ci.
2. Depending on the test configuration the developers can have conditions within the function and return a dict depending on actual values of the passed configuration.
3. Running MyPy after the provisioning step will detect potential typos early.

Benefits

While the issue was raised against opcua, this would significantly help to clean up modules.py and targetenvironment.py for other dependencies as well. Think of sql, icu,…