Qt Contributors Summit 2019 - moc and QMetaObject: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 3: Line 3:
** raw literals are an issue e.g. like in tests
** 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
*** worse, error handling is confusing and makes it hard for users to know what's going on
** can we use libclang instead of workarounds?
** 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?

Revision as of 12:35, 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?
      • 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
    • 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