in order to test for regressions in qdbusxml2cpp too.
Change-Id: Icd2a6f319c5fabf0b0f2a1fe8c70afcd2c84263e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Kevin Ottens <kevin.ottens@kdab.com>
Locking between processes, implemented with open(O_EXCL) on Unix
and CreateFile(CREATE_NEW) on Windows.
Supports detecting stale lock files and deleting them.
Advisory locking is used to prevent deletion of files that are still in use.
Change-Id: Id00ee2a4e77a29483d869037c7047c59cb909339
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Since e0839abbb4 they are created
in the build dir, not the source dir. Further, they are generated
in the include/ dir in the build dir, which is also already ignored
for in-source builds.
Change-Id: I0e709abf4b2b40351eb2728a36e9e238e3fc98bc
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
For some reference platforms and SDKs we will need to pass in
extra paths. Currently users have to modify the mkspec to adjust
paths or set environment variables that will be picked up.
This change introduces the -device <name> and -device-option
<key=value> option. The key value pairs will be written to a
qdevice.pri and can be used by the qmake.conf of the device spec.
The reason to not save the key value pairs in qconfig.pri is
becase of the fact that the device spec loads the qdevice.pri
earlier than the qconfig.pri. qdevice.pri allows the mkspec
to set the compiler flags and qconfig.pri allows configure to
add to those compiler flags.
Done-with: Holger Freyther
Change-Id: I931a197b8be72397e1eedfee09502eefc01c9d4f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Reviewed-by: Girish Ramakrishnan <girish.1.ramakrishnan@nokia.com>
Reviewed-by: Johannes Zellner <johannes.zellner@nokia.com>
Reviewed-by: Donald Carr <donald.carr@nokia.com>
Changing .gitignore to match qdoc* instead of qdoc3*.
Change-Id: I94e41e6e4371c40e0dbc33639ca02523986149b0
Reviewed-by: Casper van Donderen <casper.vandonderen@nokia.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
History of the development before the import:
ssh://codereview.qt-project.org/playground/mimetypes.git
Mimetype definitions come from shared-mime-info where available (UNIX systems),
loaded using a mmap'ed binary cache generated by update-mime-database.
As a fallback if no cache is found, we parse the raw XML files otherwise.
This makes the MIME type support fast and with very low memory usage on UNIX,
and it makes it easy to use on Windows (no dependency on shared-mime-info,
Qt even includes a freedesktop.xml file to use if none are found on the system).
Change-Id: I27b05008216ff936dc463bd80d3893422bfb940e
Reviewed-by: Richard J. Moore <rich@kde.org>
This file is generated when building qmake on Windows
Change-Id: I554bb2d32cfeff6791d664a5ca7b3d605db38c77
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
The QtV8 library is going to live in the qtjsbackend module.
Change-Id: I72251316163829411dda998b9503ce6f75b3606a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Reviewed-by: Aaron Kennedy <aaron.kennedy@nokia.com>
Reviewed-by: Kent Hansen <kent.hansen@nokia.com>
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
A V8 snapshot is a serialized representation of the JavaScript heap.
Using a snapshot can vastly speed up V8 initialization.
This commit introduces a new tool, mkv8snapshot. mkv8snapshot is
automatically invoked as part of building QtV8, and generates a .cpp
file which is compiled into the QtV8 library.
Because mkv8snapshot itself needs to initialize the V8 environment
the non-snapshot way (i.e., by evaluating thousands of lines of
JavaScript), it needs to build all of V8. This means that V8 is
effectively built twice when snapshots are enabled.
When cross-compiling, only host=i386 and target=arm is supported,
since that's the only relevant case for which V8 currently
supports a simulator. mkv8snapshot is built and run as a host tool
(using the simulator), and generates a snapshot that will be used
on the target.
Task-number: QTBUG-21152
Change-Id: I9270652f129505508f78db8b0a39fbf57dc8b86d
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
