On Monday, 18 December 2023 07:54:07 -03 Giuseppe D'Angelo via Development wrote: > If anything I think this discussion ties up with the one about the > future of moc, and whether it should become a compiler plugin. In > principle this would bypass the problem of parsing the binary module > formats -- leave it to the compiler infra, and just get the info you > need out of the `import`s.
Either that or use reflection. > > Qt should make the commitment that will support at most one module format. > > Any compiler that doesn't operate on those will not have their modules > > supported. > > > > I don't know if this is the same content that CMake had to support. It's > > possible it isn't because CMake doesn't need to know about the classes, > > enums, variables, functions, and all other entities declared, which are > > part of the translation unit. Moc does need that. > > ... which is really, what info does moc exactly need out of a #include / > import? Since 4.0 or 5.0 (too long ago) we actually parse everything included for extra information. I don't know exactly what we need from included files, but we do need something. In particular, we do need macros themselves, so we can perform proper expansion in the classes we're trying to generate meta objects for. If this is something that will never come from imports, great, it's a major barrier removed. The question is what else. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
