This fixes the NPE but not the underlying reason for the Qt plugin to be
activated. I think that might be happening because of the Codan checker
-- from what I recall, that extension point doesn't have a way to
prevent plugin activation.
The NPE is fixed by checking CACHE for null before using it. The #stop
method unregisters and sets CACHE to null. However, unregistering
doesn't prevent notifications that are already in flight. I suspect
that notification arrives, and then CACHE is null.
My test workspace would throw the NPE on every exit, with this change it
never does.
Change-Id: I01360a4c19c85fba53269d265948daf6d083c8d1
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/28751
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
features
Change-Id: I52a71e62f8161990657e96ef52403fd7f69698a2
Signed-off-by: Marc Khouzam <marc.khouzam@ericsson.com>
Reviewed-on: https://git.eclipse.org/r/27499
This means that:
- feature.xml files now make a reference to the shared license plugin
using version 0.0.0
- feature.properties files no longer have the text for the license
- license.html and epl-v10.html files are removed as they are part
of the shared license plugin
- build.properties files no longer reference removed files
- the main pom.xml file references the license repository
Change-Id: Ibd880480de3a07597084d44cce7b822903509079
Signed-off-by: Marc Khouzam <marc.khouzam@ericsson.com>
Reviewed-on: https://git.eclipse.org/r/27250
Fixing incorrect eventTypes used for registering
CProjectDescriptionListener in QMakeProjectInfo.start() method.
Change-Id: Ieb602a38999868e3da8487a1757c69bd50cb5837
Signed-off-by: David Kaspar <dkaspar@blackberry.com>
Reviewed-on: https://git.eclipse.org/r/25808
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
Adding IQMakeProjectInfo.updateQMakeInfo():QMakeInfo method to allow
explicit calculation of QMakeInfo at the time of the method call.
Change-Id: I665bedd5e095d1968f0c39ff2abb19c60aac9e14
Signed-off-by: David Kaspar <dkaspar@blackberry.com>
Reviewed-on: https://git.eclipse.org/r/23800
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
Tested-by: Doug Schaefer <dschaefer@qnx.com>
To prevent a deadlock between two the workspace and QMakeProjectInfo.sync
locks, QMakeProjectInfo class has been rewritten to not call any method
under sync-lock except for IQMakeEnv.init/destroy method.
All methods should allow calling under workspace lock.
Added a new IQMakeEnv2 interface to provide an explicit init method.
Original QMakeProjectInfo has been split to
QMakeProjectInfo and QMakeProjectInfoManager.
This change is fully backward compatible.
Change-Id: I880f22dd9bd999af1d3f47e4a3c4c0ab216b4ad2
Signed-off-by: David Kaspar <dkaspar@blackberry.com>
Reviewed-on: https://git.eclipse.org/r/23270
Tested-by: Hudson CI
Reviewed-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
view.connect( view.engine(), SIGNAL( quit() ), ...
The return type of view.engine() should be checked for the quit()
signal. The implementation was actually checking the type of view.
I've fixed a copy/paste error in a utility function.
Change-Id: Id483015214f04951fb30e3271d43499f31614446
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/21189
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
Tested-by: Doug Schaefer <dschaefer@qnx.com>
In Content Assist cases like:
q->
(when the cursor is to the right of the arrow operator) the name that is
returned by the content assist context is the empty string. This was
used to check if the QObject::connect function applied. Since the empt
string matches all bindings the Qt assistant incorrectly continued.
I've added a check to stop processing when the current name is the empty
string.
Change-Id: I4e5bf52f4ca1ddc33d88a48917213adbbeb81836
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/21188
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
Tested-by: Doug Schaefer <dschaefer@qnx.com>
The content assistant was treating all function calls in the same way.
Here is an example showing the two cases that should be handled:
qobj.connect( qobj.func(), SIGNAL( sig() ), SLOT( slot() ) );
In this case sig() applies to the return type of qobj::func() and slot()
applies to qobj (the same instance that connect is called upon).
The previous implementation of the assistant was not making a
distinction between these two cases.
I've added another test case to confirm behaviour in this area.
Change-Id: I8f76a5d5ae7384ea5162c5d36abeebb4c79c394b
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/20848
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
If a project description is changed to add the Qt nature then the PDOM
needs to be rebuilt.
Since index rebuilds are potentially expensive, this first checks to
make sure the PDOM does not already contain the QtLinkage. If the
linkage already exists, then it will be updated by the normal triggers.
The reindex operation should only be needed to add the linkage the first
time the nature is added.
This does not trigger a reindex if the nature is removed. Without the
nature, the extra linkage will be safely ignored. The C++ linkage is
(proportionally) much larger than the Qt linkage, so it doesn't make
sense to spend significant time rebuilding the index just for the small
space savings.
Change-Id: I263b05e4de407775979843f5d6a9c8c172948d72
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/20680
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
Changes:
* QtPlugin calls QMakeProjectInfo.start/stop to start/stop listening
on resource changes
* QMakeProjectInfo listens on changes in project description
e.g. changing natures
* QMakeProjectInfo.getQMakeProjectInfoFor() returns info even for
project without QtNature - this prevents race-condition that happens
when opening legacy QML projects where QtNature is added lazily after
the project is opened and somebody already asks for QMakeProjectInfo
* Fixing QMakeProjectInfo.stop() and
QMakeProjectInfo.getQMakeProjectInfoFor() to fire notification outside
of synchronized blocks
Change-Id: Ib49238f252a249d2b5936b6d8344aae93e0ef583
Signed-off-by: David Kaspar <dkaspar@blackberry.com>
Reviewed-on: https://git.eclipse.org/r/20722
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
This adds an API method to IQObject that will return the list of QML
registrations for that type.
I've also renamed the previous "QmlRegistered" to "QmlRegistration"
because it makes more sense.
The main part of this patch is a change to the QtPDOMLinkage. It now
maintains an index of the registrations that are keyed by type. The
index is a BTree that uses the QObject name as the key and a list of QML
registration PDOMNames as the value.
The list is created in the linkage's onCreate callback. Old names are
removed in the list's onDelete callback.
This includes a test case for this scenario and also updates the
previous tests to match the new naming.
Change-Id: I4b994a51958c848b4e2a3209165e6e6866e22270
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/20527
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
The Qt Codan checker for QObject::connect function calls was not
confirming that the SIGNAL and SLOT expansion parameter were Qt signals
and slots. The checker would allow the function call as long as the
expansion parameter resolved to a C++ method.
This patch changes the behaviour to required signals inside SIGNAL and
slots inside SLOT.
Change-Id: Ieec2f3a7ef4968d45ac3f6323b20c2f195fe3400
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/20401
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
The QObject::connect content assistant does not work when the receiver
of the function call is an implicit this. E.g.,
class Q : public QObject { Q_OBJECT
f()
{
this->connect( ... ); // works
connect( ... ); // does not work
QObject::connect( ... ) // does not work
}
};
I've changed the Qt's ASTUtil.getReceiverType to navigate to the
ICPPClassType through the IScope's. The previous implementation was
relying on the connect function call being an IASTField
I've also added a test case for this problem.
Change-Id: I96c29a9a452280068bda39a63414c50008bfad37
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/20399
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
The Qt spec includes a special function that is used to introduce C++
types to a namespace that is accessible from QML. E.g.,
qmlRegisterType<Q>( "uri", 1, 0, "QMLType" );
This will create a QML type called QMLType. The type will include the
signals, slots, and invokable that are defined in the C++ class Q. The
type is accessible in QML using the given URI and the version is 1.0.
More information is available at:
http://qt-project.org/doc/qt-4.8/qdeclarativeengine.html
This patch adds IQmlRegisteredType, a collection of which can be
accessed from a new method in QtIndex.
This also includes new test cases for this feature.
Change-Id: I70c44d1d8d3a0594de44e692a16f7b26396e8464
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/20347
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
This changes the Qt PDOM so that QObject's are stored using their fully
qualified name (including leading ::). IQObject's API has been changed
to return the fully qualified name. Leading :: is stripped from the
IQObject name so there is no change from the previous implementation for
names that are not inside a namspace.
This includes a new test case to check this fix.
Change-Id: I1786151463e9029cdf1f2c213466adc8c3aa3618
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/20328
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
This extends the QtIndex to support C++ classes that have been annotated
with the Q_GADGET macro. QGadgets are normal C++ classes that are able
to host Q_ENUMs.
The implementation classes for QObject have been modified to share
common parts with the implementation for QGadget. The types are
intentionally not related in the QtIndex API. This allows for divergent
changes in the Qt spec.
This patch includes new tests cases for Q_GADGET.
Change-Id: I59eb745ff5614c2897d67dd7d6807763091120af
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/20236
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
This implements a Codan checker for QObject::connect and disconnect
function calls. There are several overloads for each function, but the
basic call looks like:
Q * q;
QObject::connect( q, SIGNAL( sign() ), q, SLOT( slot() ) );
This function calls requires that Q have a Qt signal called sign and a
Qt slot called slot, e.g.,
class Q : public QObject
{
Q_OBJECT
Q_SIGNAL void sign();
Q_SLOT void slot();
};
The Qt checker raises a warning if either condition is not true.
It also raises a warning for SIGNAL or SLOT expansions without a
parameter.
Change-Id: If68a5bcdabb3f118801675e46ae926e6a250378a
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/20231
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
The QtASTVisitor is trying to use the QtIndex during indexing. Any
results available at this time are based on the state of the AST the
last time the code was indexed.
This adds a test case to reproduce the problem. The test cases indexes
the project one time. It should find two references to the signal. If
the QtIndex data is stale, then it will find 0 references.
This also replaces the code that looks for QObject::connect function
calls. The proper behaviour is to find all overloads of #connect as
well as references with QObject::disconnect (all overloads) function
calls.
A new test case checks for references in all overloads of #connect and
#disconnect function calls.
Change-Id: I28fc4213d6dddff10f81a6bd3ef01e24c74f31db
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/20223
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
The version number of the feature should have been changed when the
plugin versions were changed (in commit c6c1ef9).
Change-Id: Ia6cf07edacd8cf2932b496e09c3d0aab579e9eda
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/20068
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
This adds content assistants for QObject::connect function calls and
Q_PROPERTY expansions.
QObject::connect function calls look like:
QObject::connect(
sender, SIGNAL(someSignalFunction(int),
receiver, SLOT(someSlotFunction(int));
The assistant provides proposals in the SIGNAL and SLOT expansions. The
QObject for the corresponding type is used to create a list of signal or
slot function signatures.
Q_PROPERTY expansions look like:
Q_PROPERTY( type name READ someFunction ... )
[The ... is a list of optional attributes.] The assistant proposes
attribute names that have not yet been added. It also proposals
appropriate values for the attribute.
This patch also adds test cases for this feature.
Change-Id: I0eb25235bb423c1cfcd743075331f90f269afea7
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/19721
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
The Qt plugins have been naming internal packages using two different
prefixes:
cdt.qt.internal
cdt.internal.qt
This renames all packages to cdt.internal.qt, which seems to be the
convention for other projects.
I've increased the Qt plugin versions because alot of new API has been
added, especially to the qt.core plugin. I increased the version in the
MANIFEST.MF and pom.xml files.
I've also fixed the MANIFEST.MF files to take CDT out of the plugin
names.
I've also replaced a call to CCorePlugin.log(Exception) with a call to
QtUIPlugin.log (and added the logging functions to QtUIPlugin.
Change-Id: I1e3e7b2a42c2eb79fe33608c14a1abcf013a9f2c
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/19698
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
This adds support for Qt slots, signals, and invokables to the QtIndex.
This does not yet generate PDOM references for QObject::connection
function calls and the Content Assistant is not contributed yet.
This also fixes a problem in the GNUCPPSourceParser class (internal to
cdt.core). The class has a protected method that accepts an inner enum
as a parameter. That enum was marked as private, meaning the method
could not actually be used by subclasses. I've updated the enum to
match the visibility of the method.
There are three big areas needed to support Qt methods:
1) Slot and signal regions must be identified in the C++ class
definition. These regions are introduced with special macros and the
region extends to the next region or to the next visibility label.
Single methods can also be marked with (different) special macros.
This only applies outside of a slot/signal region.
I've created QtASTClass which examines the input class spec in order
to identify all such regions. This information is used when creating
the QtPDOM nodes for these methods.
2) Some places in Qt use type information embedded as macro expansion
parameters. The values are lost by the standard C++ parser (since they
are just text in the expansion). I've added an extension to the
GNUCPPSourceParser that accepts an input string (the macro expansion
parameter) and produces an appropriate IASTNode if possible.
3) The Qt moc follows specific and non-standard rules when matching
method signatures inside of QObject::connect function calls. I've added
a utility that creates the same signature using the CDT AST as input.
I learned the rules used by the moc by observing it's output for
significant cases. Those cases have been put into a test case that is
included in this patch.
Change-Id: If812558db315abec637653cc974abf1c0c13d95b
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/19672
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
This extends IQObject so that it can return the list of Q_PROPERTY
expansions. Each Q_PROPERTY is represented by the new IQProperty. The
attributes of the property are stored in IQProperty.Attribute.
Where applicable, the attributes insert a reference from the associated
C++ binding. This means that the Q_PROPERTY expansion will be included
in the list of references for the C++ binding.
This also simplifies the process for adding new PDOMBindings to the Qt
linkage. New instances are stored in an implementation of IQtASTName
and able to directly create and return a new QtPDOMBinding. This avoids
creating three parallel inheritance hierachies (compared to the previous
Qt PDOM implementations).
The patch includes test cases to check handling of Q_PROPERTY
expansions.
Change-Id: I7d256d1a938d24a9eb726c472fb150a02f26eb32
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/19602
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
handleEvent method updates for related project only
and does not fire listeners under 'sync' lock.
Change-Id: Id9726925ff9c044a3c13238406bdf3228ccf2933
Signed-off-by: David Kaspar <dkaspar@blackberry.com>
Reviewed-on: https://git.eclipse.org/r/19361
Reviewed-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
Tested-by: Doug Schaefer <dschaefer@qnx.com>
This replaces the QtQuick2 project wizard with Qt4 and Qt5 wizards that
include the old content as well as:
1) Make targets to build and clean the project
2) Sample interaction between C++ and QML
3) A Qt header path provider so that paths from the Qt installation are
properly resolved in the project.
Item 3 is particularly important for using the 'New Class' wizard with
QObject as the base class. Unless the Qt paths are pre-populated the
QObject base class will not be found and the New Class wizard's Finish
button will be disabled.
The Qt headers are resolved by running `qmake -query QT_INSTALL_HEADERS`
and then creating IncludePath entries for all sub-folders. This list of
include paths is persisted with other shared language settings into a
file in the workspace metadata area.
The persisted data is reloaded when any of the following change:
- the modification time of the qmake binary
- the modification time of the reported QT_INSTALL_HEADERS folder
The persisted node is ignored when the target qmake binary no longer
exists. The node is removed from the persisted form the next time that
the shared settings are persisted.
Change-Id: Ic82fdb147e6a69060f93e2e9aed2e919139a0ae9
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/16909
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
Tested-by: Doug Schaefer <dschaefer@qnx.com>
Qt allows string-based key/value pairs to be inserted into QObject class
definitions. E.g.,
class Q : public QObject
{
Q_OBJECT
Q_CLASSINFO( "key1", "value1" )
};
The class info is accessible in the meta-object system. See:
http://qt-project.org/doc/qt-4.8/qmetaclassinfo.html
For more information.
This patch adds the API to access these key/value pairs from the
QtIndex. The values are stored in a single block in the PDOM record for
the QObject.
The API returns the value for a given key if it is found in the receiver
QObject or any of its base classes. The API returns the first such
value that is found.
This patch also adds a test case for this functionality.
Change-Id: Ie3f821a0c5f6f1347a0c0c6dafa184510ae26c29
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/19154
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
Tested-by: Doug Schaefer <dschaefer@qnx.com>
The Qt meta-object system allows C++ enums to be added as simple enums
and as flags. There is more detail at:
http://qt-project.org/doc/qt-4.8/qobject.html#Q_ENUMS
and http://qt-project.org/doc/qt-4.8/qflags.html
This patch adds IQEnum to the QtIndex. IQEnums are contained in
IQObjects and therefore are accessed with the IQObject.getEnums.
An IQEnum holds its name, enumerators, and a boolean indicating whether
the instance represents a Qt flag.
A Qt flag is an enum where the enumerators are intended to be used with
bitwise operations. The Q_DECLARE_FLAGS macro is used to introduce a
type-safe container for the flags.
This patch also adds unit tests for this new functionality.
Change-Id: If51524e93533bae82a3263f3c7973a31793a8a83
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/19147
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
Tested-by: Doug Schaefer <dschaefer@qnx.com>
This uses the new PDOMASTProcessor extension point to create a
Qt-specifc PDOMLinkage. This initial version of the linkage only stores
QObjects and their base classes. Later commits will fill out other
details and introduce classes that use this data for things like Content
Assistance and Codan checking.
This patch introduces the following:
1) QtIndex: This is an index that provides access to Qt-specific data.
The index is mostly a wrapper on the CDT's existing IIndex, but it
provides very specific information about the Qt elements. The only data
that can be accessed from the QtIndex (in this patch) is a QObject and
the QObject's that appear in its base class specifier list.
2) QtPDOMLinkage: This linkage is implemenated as an extension of the
PDOMCPPLinkage. In some cases it adds references to Qt names from the
C++ bindings.
3) Test suite: The test suite has some base classes for parsing the Qt
source code. The only test case is for the simple functionality that is
being added in this patch -- examining the base class specifier list of
QObjects.
These areas will be extended in later patches.
Change-Id: I13fb83beb7f50cd2efb1de97b562245dc642468d
Signed-off-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-on: https://git.eclipse.org/r/19113
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
API is located at org.eclipse.cdt.qt.core.index package.
Entry point is QMakeProjectInfoFactory.getForActiveConfigurationIn method
that provides ability to retrieve QMake information (IQMakeInfo interface)
for active project configuration of a specified project.
Also allows to listen on changes of such information.
qmakeEnvProvider extensions allows CDT build-system to provide environment
for QMake runs within their build-system.
Information is gather by parsing output of:
1) qmake -query
2) qmake -E file.pro // only for QMake version 3.0
Change-Id: Iae569bdbc89dc26d60530596b66b5227f36dfae6
Signed-off-by: David Kaspar <dkaspar@blackberry.com>
Reviewed-on: https://git.eclipse.org/r/19082
Reviewed-by: Andrew Eidsness <eclipse@jfront.com>
Tested-by: Hudson CI
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
