On Friday 02 December 2011, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> >> You said that you can't detect this case, but why do you have to? Isn't
> >> there already a check for the Q_OBJECT macro in the cpp file? Wouldn't
> >> the logic be 'if the .moc file is included but there is no
> >>
Alexander Neundorf wrote:
>> You said that you can't detect this case, but why do you have to? Isn't
>> there already a check for the Q_OBJECT macro in the cpp file? Wouldn't
>> the logic be 'if the .moc file is included but there is no
>> Q_OBJECT in the header, then moc the .h and put the result
On Thu, Dec 1, 2011 at 3:29 PM, Alexander Neundorf wrote:
> On Thursday 01 December 2011, David Cole wrote:
> ...
>> You have two topics on the stage with common parent commits:
>> AutomocIncludedDotMocFileHandling (not presently in next) and
>> RestoreAutmocKDECompatibility (which is presently in
On Thursday 01 December 2011, David Cole wrote:
...
> You have two topics on the stage with common parent commits:
> AutomocIncludedDotMocFileHandling (not presently in next) and
> RestoreAutmocKDECompatibility (which is presently in next)...
>
> Are you planning to keep both of these, or are you
On Thu, Dec 1, 2011 at 3:18 PM, Alexander Neundorf wrote:
> On Thursday 01 December 2011, Stephen Kelly wrote:
>> Alexander Neundorf wrote:
>> > Thanks.
>> >
>> > diff --git a/tier1/solid/solid/audiointerface.cpp
>> > b/tier1/solid/solid/audiointerface.cpp
>> > index ddf6cbc..98e42b2 100644
>> > -
Alexander Neundorf wrote:
>> > but this still means that even if we start to
>> > require cmake 2.8.7 for kdelibs4, we still need the standalone automoc
>> > (which I don't feel like maintaining).
>>
>> Well, kdelibs4 is not really going to get any more releases. I'm not sure
>> it makes sense to
On Thursday 01 December 2011, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > Thanks.
> >
> > diff --git a/tier1/solid/solid/audiointerface.cpp
> > b/tier1/solid/solid/audiointerface.cpp
> > index ddf6cbc..98e42b2 100644
> > --- a/tier1/solid/solid/audiointerface.cpp
> > +++ b/tier1/solid/sol
Alexander Neundorf wrote:
> Thanks.
>
> diff --git a/tier1/solid/solid/audiointerface.cpp
> b/tier1/solid/solid/audiointerface.cpp
> index ddf6cbc..98e42b2 100644
> --- a/tier1/solid/solid/audiointerface.cpp
> +++ b/tier1/solid/solid/audiointerface.cpp
> @@ -67,4 +67,4 @@ Solid::AudioInterface::S
On Wednesday 30 November 2011, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > On Tuesday 22 November 2011, Stephen Kelly wrote:
> >> On 11/22/2011 10:03 PM, Alexander Neundorf wrote:
> >> >> Now when I try to build the frameworks branch using the cmake next
> >> >> branch, I get:
> >> >>
> >
Alexander Neundorf wrote:
> On Tuesday 22 November 2011, Stephen Kelly wrote:
>> On 11/22/2011 10:03 PM, Alexander Neundorf wrote:
>> >> Now when I try to build the frameworks branch using the cmake next
>> >> branch, I get:
>> >>
>> >> AUTOMOC: error:
>> >> /home/stephen/dev/src/kf5/tier1/libkco
On Tuesday 22 November 2011, Stephen Kelly wrote:
> On 11/22/2011 10:03 PM, Alexander Neundorf wrote:
> >> Now when I try to build the frameworks branch using the cmake next
> >> branch, I get:
> >>
> >> AUTOMOC: error:
> >> /home/stephen/dev/src/kf5/tier1/libkcoreaddons/src/io/kdirwatch.cpp: The
On 11/22/2011 10:03 PM, Alexander Neundorf wrote:
Now when I try to build the frameworks branch using the cmake next
branch, I get:
AUTOMOC: error:
/home/stephen/dev/src/kf5/tier1/libkcoreaddons/src/io/kdirwatch.cpp: The
file includes the moc file "kdirwatch_p.moc", which seems to be the moc
fil
On Tuesday 22 November 2011, Stephen Kelly wrote:
> On 11/22/2011 08:43 PM, Alexander Neundorf wrote:
> > On Tuesday 22 November 2011, Stephen Kelly wrote:
> >> On 11/10/2011 10:16 PM, Alexander Neundorf wrote:
> > ...
> >
> >>> Please give the RestoreAutmocKDECompatibility branch on cmake stage a
On 11/22/2011 08:43 PM, Alexander Neundorf wrote:
On Tuesday 22 November 2011, Stephen Kelly wrote:
On 11/10/2011 10:16 PM, Alexander Neundorf wrote:
...
Please give the RestoreAutmocKDECompatibility branch on cmake stage a
try. It should work again, but print a warning if a file includes a
mo
Alexander Neundorf wrote:
> Test added, works.
> What is not working right now is including someotherfile.moc. I could add
> special handling for including thisfile_p.moc (as opposed to
> moc_thisfile_p.cpp, which works).
Yes, this is the issue that makes the build break in the frameworks branch.
On Tuesday 22 November 2011, Stephen Kelly wrote:
> On 11/10/2011 10:16 PM, Alexander Neundorf wrote:
...
> > Please give the RestoreAutmocKDECompatibility branch on cmake stage a
> > try. It should work again, but print a warning if a file includes a
> > moc_foo.cpp, but no foo.moc, and contains a
On 11/22/2011 07:37 PM, David Faure wrote:
On Tuesday 22 November 2011 14:33:25 Stephen Kelly wrote:
I think in many cases,
fixing KDE will just be removing the explicit include "foo.moc" which is
intended to run moc on foo.h, and let the automatic moc'ing do the work.
No, to include moc_foo.
On Tuesday 22 November 2011, Alexander Neundorf wrote:
> On Tuesday 22 November 2011, Stephen Kelly wrote:
...
> > This is not uncommon in both KDE and in Qt itself, or any other project
> > where it makes sense to put a QObject-inherited class in the _p.h as an
> > internally used class. See for e
On 11/22/2011 07:10 PM, Alexander Neundorf wrote:
> find #include "(.*).moc" -> generate moc for "\\1.cpp"
> Was there a reason for preventing this?
We can do that, but how can that work ?
I mean, this will generate code for a class which is declated in a different
source file, so it is unkn
On Tuesday 22 November 2011, Stephen Kelly wrote:
> On 11/22/2011 06:20 PM, Alexander Neundorf wrote:
> > Using Qt5 or Qt4 ?
>
> Qt4.
>
> >> There seems to be several problems:
> >>
> >> * KDE does include "foo.moc" if it wants the header file to be moc'd.
> >> This is 'incorrect' compared to wh
On 11/22/2011 06:20 PM, Alexander Neundorf wrote:
Using Qt5 or Qt4 ?
Qt4.
There seems to be several problems:
* KDE does include "foo.moc" if it wants the header file to be moc'd.
This is 'incorrect' compared to what qmake expects, which would be a
"moc_foo.cpp" include.
Yes.
* Some place
On Tuesday 22 November 2011, Stephen Kelly wrote:
> On 11/10/2011 10:16 PM, Alexander Neundorf wrote:
> > On Wednesday 02 November 2011, David Faure wrote:
> >> On Monday 31 October 2011 21:47:31 Alexander Neundorf wrote:
> >>> On Monday 31 October 2011, David Faure wrote:
> This is a typical
On 11/10/2011 10:16 PM, Alexander Neundorf wrote:
On Wednesday 02 November 2011, David Faure wrote:
On Monday 31 October 2011 21:47:31 Alexander Neundorf wrote:
On Monday 31 October 2011, David Faure wrote:
This is a typical (kde) case where the .cpp incudes the .moc, for the
object defined in
On Wednesday 02 November 2011, David Faure wrote:
> On Monday 31 October 2011 21:47:31 Alexander Neundorf wrote:
> > On Monday 31 October 2011, David Faure wrote:
> > > This is a typical (kde) case where the .cpp incudes the .moc, for the
> > > object defined in the .h.
> >
> > Shouldn't it includ
On Sunday 06 November 2011, Thiago Macieira wrote:
> On Sunday, 6 de November de 2011 18:42:42 Alexander Neundorf wrote:
> > On Wednesday 02 November 2011, Stephen Kelly wrote:
> > > On 11/02/2011 06:32 PM, David Faure wrote:
> > > >> > #include "foo.moc"
> > > >> > #include "moc_foo.cpp"
> > > >
On Wednesday 02 November 2011, Stephen Kelly wrote:
> On 11/02/2011 06:32 PM, David Faure wrote:
> >> > #include "foo.moc"
> >> > #include "moc_foo.cpp"
> >> >
> >> > This would have generated twice the same moc file, I think. IMO this
> >> > is really confusing.
> >
> > Well there is no rea
On Wednesday 02 November 2011, Stephen Kelly wrote:
> On 11/02/2011 06:32 PM, David Faure wrote:
> > On Monday 31 October 2011 21:47:31 Alexander Neundorf wrote:
> > No, it's the other way around, in KDE. $ grep Q_OBJECT kautosavefile.*
> > kautosavefile.h: Q_OBJECT $ grep moc kautosavefile.cpp #in
On 11/02/2011 06:32 PM, David Faure wrote:
>
> #include "foo.moc"
> #include "moc_foo.cpp"
>
> This would have generated twice the same moc file, I think. IMO this is
> really confusing.
Well there is no reason to include both, unless you have Q_OBJECT in the .cpp
file too:-)
I'm sur
On 11/02/2011 06:32 PM, David Faure wrote:
On Monday 31 October 2011 21:47:31 Alexander Neundorf wrote:
No, it's the other way around, in KDE. $ grep Q_OBJECT kautosavefile.*
kautosavefile.h: Q_OBJECT $ grep moc kautosavefile.cpp #include
"kautosavefile.moc"
If it did additionally other things
On Monday 31 October 2011, David Faure wrote:
> Hi Alex,
>
> The latest changes in cmake-git (probably the merge of
> AutomocFindQ_OBJECTAlwaysInHeader) break the compilation of kde-frameworks.
This is for fixing http://public.kitware.com/Bug/view.php?id=12533
> Before:
>
> Generating kauthacti
30 matches
Mail list logo
