> 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? ;) _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
