[Development] Announcing moc_combine

[Oswald Buddenhagen]

> On segunda-feira, 30 de maio de 2016 17:53:48 BRT Marc Mutz wrote:
> > 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.
> 
sounds sensible.

On Mon, May 30, 2016 at 02:43:32PM -0300, Thiago Macieira wrote:
> 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
> 
that's a pretty bad test, as you're not using a file as a dep to
synchronize on.

also, we already employ a mild hack to represent compilers with multiple
outputs in several places (e.g., yacc.prf).

> 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).
> 
and why wouldn't we? it's auto-generated code ...

> > 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.
> 
can you get any more cryptic? ;)