On segunda-feira, 30 de maio de 2016 17:53:48 BRT Marc Mutz wrote: > This is orthogonal. > > Obviously, I have nothing against running moc only once per > library/executable, and applying optimisations such as string and sub-string > sharing across classes. I also have nothing against a single output file > for the tables. On the contrary. I applaud such changes. > > But I don't want QObject subclass member functions compiled into separate > TUs anymore, for the reasons cited. > > So this would meet everyones requirements: a single moc run on all headers > (and cpps) of a library, generating one output file with one large data > table, and one file per class (or file), to be included in the class' .cpp > file.
Except one requirement: the buildsytem. Each build target must produce exactly one output file. Anything else is not representable. $ gmake -f /dev/stdin foo bar <<<'foo bar: ; true' true true I also don't like that the string tables and other details would be extern symbols. Right now, they are static. For Qt code, we do have - fvisibility=hidden, but that's not required for users' code (though we could force Q_DECL_HIDDEN). > This would even preserve Q_PRIVATE_SLOT, leading to less churn (unless that > transition is desireable for other reasons than "doesn't work with > moc_combine"). It's desireable in most cases, but it's not always easy. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
