Change-Id: I91ff06644e8047c2ca483f9768b46c1372eb6171
Reviewed-by: Martin Smith <martin.smith@digia.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
Example with this code:
"template <class Key> struct QHashNode<Key, QHashDummyValue> {"
The previous regexp would take "QHashNode<Key," as some keyword,
and "QHashDummyValue>" as the class name. By forbidding '<' in the
keyword, we avoid such mistake
Change-Id: I5d5077b9e5e764e91899bcaef137d99214ea5d63
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
let the syncqt + qt_module_header.prf pair handle generation of
forwarding headers.
in qtbase this is ineffective to some degree, as the need to create
QtCore's forwarding headers early for QtBootstrap requires qtbase.pro
already doing the real work, but at least we get the verification that
nothing breaks.
Other Modules (TM) will need the full functionality.
Change-Id: Ifd3dfa05c4c8a91698a365160edb6dabc84e553f
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
since ever we've thrown out the phonon hack, each header is synced to
only one location (CamelCase headers notwithstanding).
Change-Id: Idfef33db9410908aefe309bc7a3edeae5fc5a671
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
no need to have two mechanisms for the same thing.
the values of %classnames can be comma-separated lists now, so one
header can have multiple classes assigned. conversely, if an extracted
class name reverse-maps to a different file name, it is omitted.
Change-Id: Ia0a35d64764b6376f33b77bbfe59e1df70a3cf1a
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
we run syncqt on them only to get normal forwarding headers and the
headers.pri file. the module master include header and the module
version header are useless, and scanning for qt class names just wastes
time.
Change-Id: I58e8d1eb36cea5c31cbd46ce673438316d1963dc
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
now that we split out the part that depends on the project file, we can
do it cleanly here.
this way we can generate these headers at pre-build time already.
and for git builds, perl is probably faster than qmake at this task.
Change-Id: I343255c6de22329471a3ae2c2aac9ebeb160a501
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
this avoids that syncqt needs to forward to a yet unexisting file (which
will have a yet unknown location, when syncqt is run at packaging time
already).
the %inject_headers syncqt config variable remains, so it can be told
not to purge "foreign" files.
Change-Id: I127ff6e0b7d5702fb0acaee9a5b7940b482d3608
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
there is no particular reason for it being done by qmake.
avoids that the logic is distributed over two source files,
and allows us to generate these headers at pre-build time already,
including not forwarding to a yet unexisting file (which would have a
yet unknown location).
Change-Id: I9c78ab425cf6f01d076c86fd1ee602626f231487
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
instead, rename it to syncqt.pl and rely on qtPrepareTool()'s new
ability to correctly invoke it as a perl script even under windows.
the wrappers themselves have been trivial at this point, so there is no
added value in keeping them, either.
Change-Id: I77cf65edbcfaa48ed1900defe940d4eb4b82d5b9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
