Hi,
today I learned that qmake apparently can work with #included moc files but
only if they are of the form moc_.cpp. But KDE4_AUTOMOC wants them as
.moc.
In order to make it easier to switch from qmake to cmake (and back) I suggest
the attached patch.
There's one issue I don't understand ye
Hi,
I updated the patch so that it now adds a dependency on the moc generated file
and does not add the moc files in the add_library/add_executable calls. Works
fine with a clean build dir now, too.
Please CC me as I'm not subscribed to this list.
--
__
Von: Matthias Kretz <[EMAIL PROTECTED]>
> Hi,
>
> I updated the patch so that it now adds a dependency on the moc generated
> file
> and does not add the moc files in the add_library/add_executable calls.
> Works
> fine with a clean build dir now, too.
>
Afair we had a similar discussion short
On Thursday 07 June 2007, Christian Ehrlicher wrote:
> Von: Matthias Kretz <[EMAIL PROTECTED]>
>
> > Hi,
> >
> > I updated the patch so that it now adds a dependency on the moc generated
> > file
> > and does not add the moc files in the add_library/add_executable calls.
> > Works
> > fine with a c
On Wednesday 06 June 2007 12:57, Matthias Kretz wrote:
> Hi,
>
> today I learned that qmake apparently can work with #included moc files but
> only if they are of the form moc_.cpp. But KDE4_AUTOMOC wants them as
> .moc.
>
> In order to make it easier to switch from qmake to cmake (and back) I
> su
On Friday 08 June 2007, Alexander Neundorf wrote:
> Using OBJECT_DEPENDS works more or less, but not 100%.
:( Is this a bug in cmake or is it some corner case that
add_library/add_executable works around?
> IOW we have to stay with a non-source-file extension.
How about the attached patch? It c
Alexander Neundorf said:
> IOW we have to stay with a non-source-file extension.
Yep:
*.moc for anything #included (this includes moc_*.moc, if needed)
moc_*.cpp for anything that isn't #included (but has a Q_OBJECT nonetheless)
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT)
On Friday 08 June 2007, Thiago Macieira wrote:
> Alexander Neundorf said:
> > IOW we have to stay with a non-source-file extension.
>
> Yep:
>
> *.moc for anything #included (this includes moc_*.moc, if needed)
> moc_*.cpp for anything that isn't #included (but has a Q_OBJECT
> nonetheless)
But KD
Matthias Kretz said:
> On Friday 08 June 2007, Thiago Macieira wrote:
>> Alexander Neundorf said:
>> > IOW we have to stay with a non-source-file extension.
>>
>> Yep:
>>
>> *.moc for anything #included (this includes moc_*.moc, if needed)
>> moc_*.cpp for anything that isn't #included (but has a
On Friday 08 June 2007 05:07, Matthias Kretz wrote:
> On Friday 08 June 2007, Alexander Neundorf wrote:
> > Using OBJECT_DEPENDS works more or less, but not 100%.
> >
> :( Is this a bug in cmake or is it some corner case that
>
> add_library/add_executable works around?
>
> > IOW we have to stay wi
On Saturday 09 June 2007, Alexander Neundorf wrote:
> On Friday 08 June 2007 05:07, Matthias Kretz wrote:
> > On Friday 08 June 2007, Alexander Neundorf wrote:
> > > Using OBJECT_DEPENDS works more or less, but not 100%.
> > >
> > :( Is this a bug in cmake or is it some corner case that
> >
> > add
Hi Alex,
> I think there is currently no way to tell cmake not to compile a file with a
> known extension. Even if this would be added for 2.4.7 or 2.4.8 it wouldn't
> help us since we require 2.4.5.
this bug:
http://www.cmake.org/Bug/bug.php?op=show&bugid=3908&pos=2
is fixed since 2.4.5.
So you
Hi,
On Saturday 09 June 2007 05:20, Matthias Kretz wrote:
> On Saturday 09 June 2007, Alexander Neundorf wrote:
> > On Friday 08 June 2007 05:07, Matthias Kretz wrote:
> > > On Friday 08 June 2007, Alexander Neundorf wrote:
> > > > Using OBJECT_DEPENDS works more or less, but not 100%.
> > > >
> >
On Tuesday 12 June 2007, Alexander Neundorf wrote:
> Hi,
>
> On Saturday 09 June 2007 05:20, Matthias Kretz wrote:
> > On Saturday 09 June 2007, Alexander Neundorf wrote:
> > > On Friday 08 June 2007 05:07, Matthias Kretz wrote:
> > > > On Friday 08 June 2007, Alexander Neundorf wrote:
> > > > > Us
On Saturday 16 June 2007 06:50, you wrote:
> On Tuesday 12 June 2007, Alexander Neundorf wrote:
> > Hi,
> >
> > On Saturday 09 June 2007 05:20, Matthias Kretz wrote:
> > > On Saturday 09 June 2007, Alexander Neundorf wrote:
> > > > On Friday 08 June 2007 05:07, Matthias Kretz wrote:
> > > > > On Fr
On Monday 18 June 2007, Alexander Neundorf wrote:
> On Saturday 16 June 2007 06:50, you wrote:
> > On Tuesday 12 June 2007, Alexander Neundorf wrote:
> > > Hi,
> > >
> > > On Saturday 09 June 2007 05:20, Matthias Kretz wrote:
> > > > On Saturday 09 June 2007, Alexander Neundorf wrote:
> > > > > On
On Monday 18 June 2007, Alexander Neundorf wrote:
> So you didn't have any problems ?
See kdepim/kresources/groupdav/CMakeLists.txt lines 17 and 48. It defines two
different targets with the same target name. The same on lines 31 and 63.
This results in the _automoc.files file to be overwritten
On Monday 18 June 2007 19:13, Matthias Kretz wrote:
> On Monday 18 June 2007, Alexander Neundorf wrote:
> > So you didn't have any problems ?
>
> See kdepim/kresources/groupdav/CMakeLists.txt lines 17 and 48. It defines
> two different targets with the same target name. The same on lines 31 and
> 6
On Monday 18 June 2007 7:13:01 pm Matthias Kretz wrote:
> On Monday 18 June 2007, Alexander Neundorf wrote:
> > So you didn't have any problems ?
>
> See kdepim/kresources/groupdav/CMakeLists.txt lines 17 and 48. It defines two
> different targets with the same target name. The same on lines 31 a
Is it ok if I commit the KDE4Macros.cmake change to make the delayed automoc
work? Or do you want to do it? Any showstoppers with it?
I just committed my patch to kde4automoc.cmake to make the moc include qmake
compatible there...
--
Mat
On Friday 22 June 2007, Matthias Kretz wrote:
> Is it ok if I commit the KDE4Macros.cmake change to make the delayed automoc
> work? Or do you want to do it? Any showstoppers with it?
Alex?
> I just committed my patch to kde4automoc.cmake to make the moc include qmake
> compatible there...
Thank
don't have David's mail here for replying to it...
but attached is a patch to create the .moc file from the .cpp file if the .cpp
file matches ^\s*Q_OBJECT. For moc_foo.cpp files it always creates it from
the .h file. That way you can include both
#include "moc_foo.cpp"
#include "foo.moc"
and w
Matthias Kretz wrote:
>don't have David's mail here for replying to it...
>
>but attached is a patch to create the .moc file from the .cpp file if
> the .cpp file matches ^\s*Q_OBJECT. For moc_foo.cpp files it always
> creates it from the .h file. That way you can include both
>#include "moc_foo.cp
On Tuesday 26 June 2007, Thiago Macieira wrote:
> Matthias Kretz wrote:
> >don't have David's mail here for replying to it...
> >
> >but attached is a patch to create the .moc file from the .cpp file if
> > the .cpp file matches ^\s*Q_OBJECT. For moc_foo.cpp files it always
> > creates it from the
David Faure wrote:
>On Tuesday 26 June 2007, Thiago Macieira wrote:
>> Matthias Kretz wrote:
>> >don't have David's mail here for replying to it...
>> >
>> >but attached is a patch to create the .moc file from the .cpp file if
>> > the .cpp file matches ^\s*Q_OBJECT. For moc_foo.cpp files it always
On Tuesday 26 June 2007, Thiago Macieira wrote:
> David Faure wrote:
> >On Tuesday 26 June 2007, Thiago Macieira wrote:
> >> Matthias Kretz wrote:
> >> >don't have David's mail here for replying to it...
> >> >
> >> >but attached is a patch to create the .moc file from the .cpp file if
> >> > the .
David Faure wrote:
>On Tuesday 26 June 2007, Thiago Macieira wrote:
>> David Faure wrote:
>> >> Only *.moc files should be included.
>> >
>> >You're talking about qmake? I tested with foo.cpp including both
>> > moc_foo.cpp and foo.moc (when both foo.cpp and foo.h have a
>> > Q_OBJECT) and it worke
On Tuesday 26 June 2007 08:02, David Faure wrote:
> On Friday 22 June 2007, Matthias Kretz wrote:
> > Is it ok if I commit the KDE4Macros.cmake change to make the delayed
> > automoc work? Or do you want to do it? Any showstoppers with it?
>
> Alex?
Not from my side.
One thing is that now all file
On Wednesday 27 June 2007, Alexander Neundorf wrote:
> Could you maybe measure cmake times with the old and the new one with cold
> and warm caches ?
Measuring is almost impossible. Using
time cmake
I get +/- 50% on total time. But here are the numbers:
old automoc:
without cache: 39.47s user 12.
On Wednesday 27 June 2007 18:26, Matthias Kretz wrote:
> On Wednesday 27 June 2007, Alexander Neundorf wrote:
> > Could you maybe measure cmake times with the old and the new one with
> > cold and warm caches ?
>
> Measuring is almost impossible. Using
> time cmake
> I get +/- 50% on total time. Bu
Alex wrote:
> On Wednesday 27 June 2007 18:26, Matthias Kretz wrote:
> > old automoc:
> > without cache: 39.47s user 12.53s system 36% cpu 2:22.32 total
> > withcache: 16.59s user 2.62s system 26% cpu 1:13.69 total
> >
> > new automoc as from Alex's patch:
> > without cache: 38.78s user 12.06s
On Thursday 28 June 2007 11:20, Matthias Kretz wrote:
> Alex wrote:
> > On Wednesday 27 June 2007 18:26, Matthias Kretz wrote:
> > > old automoc:
> > > without cache: 39.47s user 12.53s system 36% cpu 2:22.32 total
> > > withcache: 16.59s user 2.62s system 26% cpu 1:13.69 total
> > >
> > > new
On Friday 29 June 2007, Alexander Neundorf wrote:
> On Thursday 28 June 2007 11:20, Matthias Kretz wrote:
> > after that it seems to work, at least my stuff. Here's an error I didn't
> > look into:
> > Scanning dependencies of target globalcleanuptest
> > [ 8%] Building CXX object
> > kdecore/test
On Jul 1, 2007, at 3:19 PM, Matthias Kretz wrote:
> On Friday 29 June 2007, Alexander Neundorf wrote:
>> On Thursday 28 June 2007 11:20, Matthias Kretz wrote:
>>> after that it seems to work, at least my stuff. Here's an error I
>>> didn't
>>> look into:
>>> Scanning dependencies of target glob
34 matches
Mail list logo
