[Development] Announcing moc_combine

[Thiago Macieira]

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