On domingo, 29 de maio de 2016 13:05:07 PDT Thiago Macieira wrote:
> I've just pushed a feature[1]
Change is now abandoned due to lack of volunteers to modify qmake to generate
a suitable Makefile.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source
On terça-feira, 31 de maio de 2016 15:29:45 BRT Thiago Macieira wrote:
> The following extra rules solve the problem, at the expense of causing Qt
> Creator to complain that the header you had opened changed every time you
> build:
[cut]
> Proof:
> $ gmake
> moc --combine=%.h=.moc/moc_%.cpp 1.h
On terça-feira, 31 de maio de 2016 15:14:41 BRT Thiago Macieira wrote:
> On terça-feira, 31 de maio de 2016 14:42:01 BRT Thiago Macieira wrote:
> > Also, qmake would need to list only the actual headers, not the indirect
> > dependencies of them as it currently does. That would mean moc would not
On 31/05/2016 19:42, Thiago Macieira wrote:
This feature is nice for source distributions but isn't suitable for
code being developed.
We can easily disable it for developer builds.
Yes, please!
But note that due to rebases and touching central files like qglobal.h or
qobject.h,
On terça-feira, 31 de maio de 2016 14:42:01 BRT Thiago Macieira wrote:
> The best of both worlds would be if:
> * moc could output more than one file
> * moc could be run once for however many files needed updating
> * moc could be given the list of files that have changed, but no others
[cut]
On terça-feira, 31 de maio de 2016 18:13:18 BRT Joerg Bornemann wrote:
> While this feature reduces the build time for full builds within a
> measurable range, it drastically increases build time for incremental
> builds. Changing just one Q_OBJECT header file results in full
> regeneration of
On terça-feira, 31 de maio de 2016 09:45:40 BRT Olivier Goffart wrote:
> > the next idea would be implementing moc inside the compiler itself,
> > which is possible with at least clang and gcc nowadays.
> >
> > the last idea is doing away with moc entirely, at the cost of somewhat
> > uglier
On 29/05/2016 18:05, Thiago Macieira wrote:
I've just pushed a feature[1] to moc that makes it process multiple headers at
the same time, producing only one output file, and a second feature[2] that
"precompiles" a header. Since moc is single-threaded, this often means more
wall-clock time than
On terça-feira, 31 de maio de 2016 11:24:14 BRT Oswald Buddenhagen wrote:
> > > 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
> 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'
On Montag, 30. Mai 2016 11:16:00 CEST Oswald Buddenhagen wrote:
> On Mon, May 30, 2016 at 10:19:38AM +0200, Marc Mutz wrote:
> > On Sunday 29 May 2016 18:05:07 Thiago Macieira wrote:
> > > I've just pushed a feature[1] to moc that makes it process multiple
> > > headers
> > > at the same time,
On segunda-feira, 30 de maio de 2016 17:58:44 BRT Marc Mutz wrote:
> On Monday 30 May 2016 15:12:01 Thiago Macieira wrote:
> > Sorry, I don't buy it. Instead:
> > qmake -config ltcg
>
> I take that "I don't buy it" means that link-time compilation also warns
> about unused data and
On Monday 30 May 2016 15:12:01 Thiago Macieira wrote:
> Sorry, I don't buy it. Instead:
> qmake -config ltcg
I take that "I don't buy it" means that link-time compilation also warns about
unused data and function members?
Anyway, until such a time as that becomes the default build mode
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
On Monday 30 May 2016 16:24:38 Jędrzej Nowacki wrote:
> On Monday 30 of May 2016 10:19:38 Marc Mutz wrote:
> > On Sunday 29 May 2016 18:05:07 Thiago Macieira wrote:
> > > I've just pushed a feature[1] to moc that makes it process multiple
> > > headers
> > > at the same time, producing only one
On segunda-feira, 30 de maio de 2016 10:12:01 BRT Thiago Macieira wrote:
> Em segunda-feira, 30 de maio de 2016, às 10:19:38 BRT, Marc Mutz escreveu:
> > On Sunday 29 May 2016 18:05:07 Thiago Macieira wrote:
> > > I've just pushed a feature[1] to moc that makes it process multiple
> > > headers
>
On Monday 30 of May 2016 10:19:38 Marc Mutz wrote:
> On Sunday 29 May 2016 18:05:07 Thiago Macieira wrote:
> > I've just pushed a feature[1] to moc that makes it process multiple
> > headers
> > at the same time, producing only one output file
>
> Separate compilation is not how I would
On Mon, May 30, 2016 at 10:19:38AM +0200, Marc Mutz wrote:
> On Sunday 29 May 2016 18:05:07 Thiago Macieira wrote:
> > I've just pushed a feature[1] to moc that makes it process multiple headers
> > at the same time, producing only one output file
>
> Separate compilation is not how I would
On Sunday 29 May 2016 18:05:07 Thiago Macieira wrote:
> I've just pushed a feature[1] to moc that makes it process multiple headers
> at the same time, producing only one output file
Separate compilation is not how I would recommend to use moc-generated files.
I'd recommend to always include
Em domingo, 29 de maio de 2016, às 13:05:07 BRT, Thiago Macieira escreveu:
> - simple connect() statements (even supports Qt::UniqueConnection, provided
> that you're connecting PMFs [note: there might be bugs!!])
Confirmed:
https://bugreports.qt.io/browse/QTBUG-53684
--
Thiago Macieira -
I've just pushed a feature[1] to moc that makes it process multiple headers at
the same time, producing only one output file, and a second feature[2] that
"precompiles" a header. Since moc is single-threaded, this often means more
wall-clock time than the previous case, but it's always less CPU
21 matches
Mail list logo
