wlav

The docs has an example: https://cppyy.readthedocs.io/en/latest/utilities.html#dictionaries The cmake interface uses `rootcling`: https://cppyy.readthedocs.io/en/latest/cmake_interface.html The tests have both `genreflex` (Linux/Mac, see `Makefile`) and `rootcling` (Windows, see `make_dict_win32.py`) examples: https://github.com/wlav/cppyy/tree/master/test Not developed for...

Yes, it's not until an object is used when the headers are parsed. (I'll add that `IsEnum()` is overly greedy.) Are the headers importable with `cppyy.include()`? Otherwise, how many `using`...

I'll ask whether there's anything that they know of that could cause this.

That failure itself is in meta, which would be called until parsing completed successfully. But otherwise yes, it's a `using` and already problematic to some extend.

I checked, and for `cppyy.include()`, auto-loading is off: ``` SuspendAutoloadingRAII autoLoadOff(this); SuspendAutoParsing autoParseRaii(this); ``` so it definitely take a different path through the code.

Can you try setting: ``` c = cppyy.gbl.CppyyLegacy.TInterpreter.SuspendAutoParsing(cppyy.gbl.gInterpreter) ``` before loading anything? The above is a RAII, so auto-parsing is (should be) disabled until that variable is deleted.

Upstream asks whether using a `typedef` instead of `using` makes a difference and to check you included all header files, in particular the STL ones.

There's a file called `allHeaders.h` which you can find under `cppyy_backend/etc/dictpch'. This is used by the `makepch.py` script in the same directory that cppyy calls on startup if the PCH...

Something like this: https://github.com/compiler-research/CppInterOp/issues/302#issuecomment-2576684388 may eventually lead to using multiple PCHs and faster parsing/instantiation times. Note that there is a solution to multiple PCHs, namely modules. However, Cling doesn't use...