Qt Contributors Summit 2019 - moc and QMetaObject: Difference between revisions
Jump to navigation
Jump to search
Milian Wolff (talk | contribs) No edit summary |
Milian Wolff (talk | contribs) No edit summary |
||
Line 5: | Line 5: | ||
** can we use libclang instead of workarounds? see moc-ng | ** can we use libclang instead of workarounds? see moc-ng | ||
*** libclang can be quite slow, but we already did it for lupdate and qdoc | *** libclang can be quite slow, but we already did it for lupdate and qdoc | ||
*** roughly an order of magnitude slower, but we could do better? | *** roughly an order of magnitude slower, but we could do better? => this is the biggest issue probably | ||
*** when using build farms, moc is a bottleneck - unless it could be distributed but that doesn't sound feasible | *** when using build farms, moc is a bottleneck - unless it could be distributed but that doesn't sound feasible | ||
*** bootstrapping is quasi impossible when using libclang, we'd have to port moc to not use C++ anymore | *** bootstrapping is quasi impossible when using libclang, we'd have to port moc to not use C++ anymore | ||
*** size of libclang + dependencies is only an issue for developer machines, roughly ~80mb | *** size of libclang + dependencies is only an issue for developer machines, roughly ~80mb | ||
*** windows headers should be supported nowadays | *** windows headers should be supported nowadays | ||
*** libclang C api can be used, C++ api isn't stable, not a good idea | *** libclang C api can be used, C++ api isn't stable, not a good idea probably - need to stay compatible with trunk continuously otherwise | ||
** why can't we use something easier than libclang? | ** why can't we use something easier than libclang? | ||
*** parsing C++ is actually very hard with some C++ changes recently | *** parsing C++ is actually very hard with some C++ changes recently |
Revision as of 12:43, 21 November 2019
- breaking ABI allows for performance changes and additional features in QMetaObject
- what about newer C++ features
- raw literals are an issue e.g. like in tests
- worse, error handling is confusing and makes it hard for users to know what's going on
- can we use libclang instead of workarounds? see moc-ng
- libclang can be quite slow, but we already did it for lupdate and qdoc
- roughly an order of magnitude slower, but we could do better? => this is the biggest issue probably
- when using build farms, moc is a bottleneck - unless it could be distributed but that doesn't sound feasible
- bootstrapping is quasi impossible when using libclang, we'd have to port moc to not use C++ anymore
- size of libclang + dependencies is only an issue for developer machines, roughly ~80mb
- windows headers should be supported nowadays
- libclang C api can be used, C++ api isn't stable, not a good idea probably - need to stay compatible with trunk continuously otherwise
- why can't we use something easier than libclang?
- parsing C++ is actually very hard with some C++ changes recently
- we only need to parse a few things correctly, but we have to ignore all of the rest properly, which is tough
- for qt6 we could remove old system to use moc without passing include paths, i.e. hard error if file is missing
- raw literals are an issue e.g. like in tests
- when we need to extend moc, do we extend the old one or do we build a new tool based on top of libclang and add the new features there?