| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Newer clang versions seem to expose serious bugs in QtScript, whose
complexity makes it difficult to track them down.
We therefore switch to the more light-weight QuickJS, which offers all
the features we need (most notably property access interception), as
well as good performance.
To save some porting effort, we removed the long-deprecated loadFile()
and loadExtension() functions.
During the porting procedure, we noticed and fixed thread safety issues
in artifact access from JS commands.
We consider this change important enough to bump the major version, so
the next release will be 2.0.
Detailed benchmarking data is below. In summary, we see a modest speed-
up at the cost of a similarly modest increase in memory consumption
(with the exception of project resolving on macOS, which has become a
bit slower). Importantly, the increase does not rise with project size,
as the comparison of qbs vs Qt Creator shows.
Output of qbs_benchmarker on Linux with qbs as test project:
========== Performance data for Resolving ==========
Old instruction count: 12870602895
New instruction count: 11923459780
Relative change: -8 %
Old peak memory usage: 61775848 Bytes
New peak memory usage: 67583424 Bytes
Relative change: +9 %
========== Performance data for Rule Execution ==========
Old instruction count: 4074062223
New instruction count: 3887473574
Relative change: -5 %
Old peak memory usage: 35123704 Bytes
New peak memory usage: 38398392 Bytes
Relative change: +9 %
========== Performance data for Null Build ==========
Old instruction count: 1104417596
New instruction count: 1011033948
Relative change: -9 %
Old peak memory usage: 24461824 Bytes
New peak memory usage: 25325920 Bytes
Relative change: +3 %
Output of qbs_benchmarker on Linux with Qt Creator as test project:
========== Performance data for Resolving ==========
Old instruction count: 67166450352
New instruction count: 60772791018
Relative change: -10 %
Old peak memory usage: 327011616 Bytes
New peak memory usage: 343724176 Bytes
Relative change: +5 %
========== Performance data for Rule Execution ==========
Old instruction count: 71684351183
New instruction count: 67051936965
Relative change: -7 %
Old peak memory usage: 374913688 Bytes
New peak memory usage: 387790992 Bytes
Relative change: +3 %
========== Performance data for Null Build ==========
Old instruction count: 8383156078
New instruction count: 7930705668
Relative change: -6 %
Old peak memory usage: 180468360 Bytes
New peak memory usage: 182490384 Bytes
Relative change: +1 %
Real-world data building Qt Creator (using qbs --log-time, several runs,
removing outliers):
macOS:
Resolving: 43s -> 47s
Rule execution: 17s -> 14s
Windows:
Resolving: 18s -> 16s
Rule execution: 22s -> 17s
Fixes: QBS-913
Fixes: QBS-1103
Fixes: QBS-1126
Fixes: QBS-1227
Fixes: QBS-1684
Change-Id: Ie5088155026e85bbd1e303f1c67addb15810a3cb
Reviewed-by: Ivan Komissarov <ABBAPOH@gmail.com>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
|
| |
|
|
|
|
|
|
|
|
| |
Array.isArray() seemed to work for arrays created in scripts as well as
for QStringList and QVariantList created in C++ when using QtScript.
QJSEngine is more strict (see the comments in QTBUG-45018). One way to
work around that problem is to use instanceof Array instead.
Change-Id: I0f1c8757a5ab2f82e26eff19a8b5ecf667bb04b1
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
|
| |
|
|
|
|
|
|
| |
This reduces execution time to 1s (was 10s) and simplifies PathProbe
debugging because the cpp module contains probes as well.
Change-Id: Iddd4de71143892d6815acbd1efff30f92d70a423
Reviewed-by: Ivan Komissarov <ABBAPOH@gmail.com>
|
| |\
| |
| |
| | |
Change-Id: Ibdf2afb9f05682e0624540af22330abc8580bafb
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Within the groups of user-provided and system-provided paths,
environment variables need to take precedence over properties, because
there is currently no other way to override the search paths of probes
from the outside if the probe-using code did not explicitly bind them to
Product/Module properties.
We search directly user-provided paths before ones from system-provided
environment variables to minimize the risk of surprises due to outside
influence.
[ChangeLog][Behavior Changes] The lookup order in PathProbe changed to
[environmentPaths, searchPaths, platformEnvironmentPaths,
platformSearchPaths]
Change-Id: Ib0c3bc44e5a8efaaaa073f28f1f3a53feb0f78db
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This testcase uses relative paths both as input properties to PathProbe
and as expected results (rhs). The obtained output properties (lhs) are
relative paths, too and as such, a simple string comparison is performed
to verify the results. While this currently works, it is not correct to
do so.
PathProbe features input and output properties of pathList type and
thus, when reading these properties, returned values should always be
absolute file paths. It is a known problem that path properties in
probes are not absolutified, which will be fixed when porting to
QJSEngine. Thus, we need to absolutify the expected values when
evaluating the results.
In order to remain compatible with the current implementation, we need
to do the absolutification on both sides.
Change-Id: I13c7655f509179f3778c736e08fbd1bd264a63c4
Reviewed-by: Ivan Komissarov <ABBAPOH@gmail.com>
|
| |
|
|
|
|
|
|
|
|
| |
It is not possible to use functions as values for properties with the
new JS engine.
Remove nameFilter by allowing to have common nameSuffixes for different
selectors.
Change-Id: I24ae747f4d609c956285e77ee832c6e99304a622
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add checks for the candidatePaths and the single file API.
Also, this includes a behavior change - if multiple selectors are
present, the filePath/fileName/path probe properties are not set up -
this is because it is not clear how they should be set up in case when
the first file in selectors is found, but the second is not (and thus
probe.found is false). In case of multiple selectors, user should use
probe.allResults but not the single file API.
Change-Id: Ib56faf0de93d3ec9fc49f5dbc9d51d4b36831a2d
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This property can be used to check if candidate conforms with some
conditions. For example, an architecture of a shared
library candidate should match the current qbs.architecture.
Also, this will allow to implement support for the "text based stub
libraries" (yaml files that point to a real library in a system) on
macOS - instead of checking real file architecture, it should be read
from .tbd file
Change-Id: Ie84a3e70d883dec949440358e2f08213a8501982
Reviewed-by: Qbs CI Bot <travis-bot@weickelt.de>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
|
|
|
Change-Id: I6ae2dd130cbafb03e51bc6e8e8a3e262d6d45fc6
Reviewed-by: Qbs CI Bot <travis-bot@weickelt.de>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
|
