Hello,
It's a follow up for http://bugs.kde.org/show_bug.cgi?id=160976. Please read
this bug report for the background on the issue. Short description of the
patches can be found in the bug report too.
First of all, the patch (97th) [1] should be compatible with cmake 2.4.x. If
kdelibs is comp
On Monday 28 April 2008, Modestas Vainius wrote:
> Hello,
>
> It's a follow up for http://bugs.kde.org/show_bug.cgi?id=160976. Please
> read this bug report for the background on the issue. Short description of
> the patches can be found in the bug report too.
>
> First of all, the patch (97th) [1]
Hello,
2008 m. April 28 d., Monday, Alexander Neundorf rašė:
>Pro:
>-your patches look good
>-I think you are right
Great.
>-cmake 2.6.0 is not released yet and we are already at alpha1 stage of KDE
4.1
Yep, but it is very very near.
> Depending on how we deal with the compatibility problem, I'
On Monday 28 April 2008, Alexander Neundorf wrote:
> -cmake 2.6.0 is not released yet and we are already at alpha1 stage of KDE
> 4.1 -the patches kind-of break source compatibility
not really.. apps that break due to that are invalid anyway. for every 3rd
party module which we depend on and tha
On Tuesday 06 May 2008, Dirk Mueller wrote:
> Thats one solution - another solution is to make it optinally available
> now, so that distributions can fix the migration path, and make it a
> requirement with KDE 4.2 (or maybe even 4.1).
I forgot to add: Alex do you object to it being available op
On Tuesday 06 May 2008, Dirk Mueller wrote:
> On Monday 28 April 2008, Alexander Neundorf wrote:
> > -cmake 2.6.0 is not released yet and we are already at alpha1 stage of
> > KDE 4.1 -the patches kind-of break source compatibility
>
> not really.. apps that break due to that are invalid anyway. fo
On Saturday 10 May 2008, you wrote:
> > > , stuff which links with
> > > KDE 4.0.x may not link anymore once this patch is applied
> >
> > thats the reason why the patch should be applied to be able to
> > optionally use this feature as soon as possible, so that those who care
> > (I count debian
On Saturday 10 May 2008, Sune Vuorela wrote:
> On Saturday 10 May 2008, you wrote:
> > > > , stuff which links with
> > > > KDE 4.0.x may not link anymore once this patch is applied
> > >
> > > thats the reason why the patch should be applied to be able to
> > > optionally use this feature as soon
> This means you will be here on kde-buildsystem and kde-core-devel and care
> for
> all emails which report linking problems, independent from which
> distribution
> they are using ?
This is already what we do:
be here on kde-buildsystem and kde-core-devel and care for KDE users
independent from
On Saturday 10 May 2008, Sune Vuorela wrote:
> On Saturday 10 May 2008, you wrote:
> > > > , stuff which links with
> > > > KDE 4.0.x may not link anymore once this patch is applied
> > >
> > > thats the reason why the patch should be applied to be able to
> > > optionally use this feature as soon
Hi,
2008 m. May 20 d., Tuesday, Alexander Neundorf rašė:
> What would you think about installing a KDELibsDependencies.cmake with
> different contents ?
> This could be done either by:
> -postprocessing the file created from kdelibs by the distros
> or by
I don't quite understand what you want to
On Tuesday 20 May 2008, you wrote:
> Hi,
>
> 2008 m. May 20 d., Tuesday, Alexander Neundorf rašė:
> > What would you think about installing a KDELibsDependencies.cmake with
> > different contents ?
> > This could be done either by:
> > -postprocessing the file created from kdelibs by the distros
>
On Wednesday 21 May 2008, Alexander Neundorf wrote:
...
> > Well, that's not a bad idea. kdelibs and kdepimlibs can generate two
> > dependency files with cmake 2.6:
> >
> > 1) Old with _LIB_DEPENDS.
> > 2) New with IMPORTED targets and LINK_INTERFACE_LIBRARIES in effect.
>
> Please update kdelibs
Hello,
Monday 26 May 2008, Alexander Neundorf ra:
> Dirk, Sune, Modestas, any comments or interest in this ?
Thanks, it's already in use in Debian (for 4.0.80) and end results seem to be
fully compatible with my previous kdelibs 97 patch. However, I have a few
suggestions:
1) Could you split de
On Monday 26 May 2008, you wrote:
> Hello,
>
> Monday 26 May 2008, Alexander Neundorf ra:
> > Dirk, Sune, Modestas, any comments or interest in this ?
>
> Thanks, it's already in use in Debian (for 4.0.80) and end results seem to
> be fully compatible with my previous kdelibs 97 patch. However, I h
On Monday 26 May 2008, Alexander Neundorf wrote:
> > This means to make this work for you you have to set the
> > LINK_INTERFACE_LIBRARIES property for the library targets. This shouldn't
> > be a problem no matter whether you are using cmake 2.4.x, cmake 2.6.x or
> > whether this option is enable
On Thursday 29 May 2008, Dirk Mueller wrote:
...
> All fine for me, go ahead. I can help with fixing/testing it somewhen end
> of next week.
Ok, done.
On Tuesday 03 June 2008, Modestas Vainius wrote:
> Hi,
>
> Tuesday 03 June 2008, jūs rašėte:
> > As discussed with Dirk, make the link interface e
On Tuesday 03 June 2008, Alexander Neundorf wrote:
> On Thursday 29 May 2008, Dirk Mueller wrote:
> ...
>
> > All fine for me, go ahead. I can help with fixing/testing it somewhen end
> > of next week.
>
> Ok, done.
>
> On Tuesday 03 June 2008, Modestas Vainius wrote:
> > Hi,
> >
> > Tuesday 03 Jun
Hi,
On Wednesday 11 June 2008, Alexander Neundorf wrote:
> On Tuesday 03 June 2008, Alexander Neundorf wrote:
> > On Thursday 29 May 2008, Dirk Mueller wrote:
> > ...
> >
> > > All fine for me, go ahead. I can help with fixing/testing it somewhen
> > > end of next week.
> >
> > Ok, done.
> >
> > O
2008/6/18 Alexander Neundorf <[EMAIL PROTECTED]>:
> i.e. almost empty. I don't know if these settings are ideal. There were a lot
> of undefined references to X stuff in targets which linked to kdeui, so maybe
> X11_LIBRARIES should be added to the link interface of kdeui.
> There were also severa
On Thursday 19 June 2008, you wrote:
> 2008/6/18 Alexander Neundorf <[EMAIL PROTECTED]>:
> > i.e. almost empty. I don't know if these settings are ideal. There were a
> > lot of undefined references to X stuff in targets which linked to kdeui,
> > so maybe X11_LIBRARIES should be added to the link
On Thursday 19 June 2008, Alexander Neundorf wrote:
> Hi,
>
> On Wednesday 11 June 2008, Alexander Neundorf wrote:
> > On Tuesday 03 June 2008, Alexander Neundorf wrote:
> > > On Thursday 29 May 2008, Dirk Mueller wrote:
> > > ...
> > >
> > > > All fine for me, go ahead. I can help with fixing/test
Hi,
Tuesday 24 June 2008, Alexander Neundorf rašė:
> After you pushed so much, is there now actually any interest in this ?
Yes, I pushed it and had done that for a month and a half, but, unfortunately,
my time is very limited now to look into this. At the first sight, I still see
some excess st
On Tuesday 24 June 2008, Alexander Neundorf wrote:
> After you pushed so much, is there now actually any interest in this ?
there is interest, I have a local project which builds (well, doesn't build)
with the experimental link-reduction. I've been wondering though why you're
not committing the
On Wednesday 25 June 2008, Dirk Mueller wrote:
> On Tuesday 24 June 2008, Alexander Neundorf wrote:
> > After you pushed so much, is there now actually any interest in this ?
>
> there is interest, I have a local project which builds (well, doesn't
> build) with the experimental link-reduction. I'v
On Thursday 26 June 2008, Alexander Neundorf wrote:
> Currently this patch does two things
> -it adds more libs to the TARGET_LINK_LIBRARIES() calls - wouldn't hurt to
> commit that part
exactly, and it is the right thing to do.
> -it sets the LINK_INTERFACE_LIBRARIES target property - this can
On Thursday 26 June 2008, Dirk Mueller wrote:
> On Thursday 26 June 2008, Alexander Neundorf wrote:
> > Currently this patch does two things
> > -it adds more libs to the TARGET_LINK_LIBRARIES() calls - wouldn't hurt
> > to commit that part
>
> exactly, and it is the right thing to do.
Done.
Atta
Hello,
Ok, my comments about your reduced_linking_2.patch can be found below:
> khtml
> LINK_INTERFACE_LIBRARIES "kparts;kjs;kio;kdeui;kdecore"
Please drop kjs. It is definitely excess here because none of our
target_link_libraries fixes has ever included it.
> krosscore
> LINK_INTERFACE_LIBRAR
On Sunday 29 June 2008, Modestas Vainius wrote:
> Hello,
>
> Ok, my comments about your reduced_linking_2.patch can be found below:
Thanks for reviewing :-)
> > khtml
> > LINK_INTERFACE_LIBRARIES "kparts;kjs;kio;kdeui;kdecore"
>
> Please drop kjs. It is definitely excess here because none of our
Alexander Neundorf wrote:
>> The only QtXml user is kross/core/action.h
>> fromDomElement/toDomElement. I don't think this is enough to link all
>> krosscore users against QtXml.
>
>Hmm, is it a real problem if QtXml is listed here ? It shouldn't add
> more package dependencies (QtXml should be ins
On Monday 30 June 2008, you wrote:
> Alexander Neundorf wrote:
> >> The only QtXml user is kross/core/action.h
> >> fromDomElement/toDomElement. I don't think this is enough to link all
> >> krosscore users against QtXml.
> >
> >Hmm, is it a real problem if QtXml is listed here ? It shouldn't add
>
Hi,
Monday 30 June 2008, Alexander Neundorf rašė:
> I think keeping some libs for convenience there is ok, as long as this
> doesn't result in bigger problems.
I agree with this but only for transitional period since it is getting very
late for KDE 4.1. So I suggest the following. Lets do a prope
On Monday 30 June 2008, Thiago Macieira wrote:
> >> The only QtXml user is kross/core/action.h
> The point is that most applications won't be using QtXml symbols, so they
> shouldn't be linking *directly* to QtXml. If they do use them, then they
> should link.
In some cases, there is no way to us
Am Montag, 30. Juni 2008 schrieb Modestas Vainius:
> 2) KDE 4.1 branch will be more compatible with older 3rd party kde4
> applications. Please have in mind that this experimental linking will
> probably be enabled by some distros (Debian at least however we are not
> going to ship full KDE 4.1 i
Leo Savernik wrote:
>If somebody intends to write a hypothetical kde command line app
> depending only on qtcore and kdecore without gui and without dbus,
> loading and execution shouldn't suffer by dragging in QtDBus. I think
> KDE 4 *should* support lean and fast command line apps.
kdecore loads
2008/6/30 Thiago Macieira <[EMAIL PROTECTED]>:
> kdecore loads QtDBus *anyways*. That's not the question here.
>
> The question is whether the application should link directly to QtDBus.
And AFAIK on OSX these two are synonymous, the application must link
all indirect symbols. But I'd like to co
On Monday 30 June 2008, Alexander Neundorf wrote:
> > Could you please justify QtNetwork and QtXml here? None of public kio
> > headers need QtNetwork (actually, QtNetwork is not worth bundling with
> > anything). QtXml users are kbookmark*.h (internal method) and davjob.h.
> > In my opinion, they
On Friday 27 June 2008, Alexander Neundorf wrote:
> > +macro (KDE4_TARGET_LINK_INTERFACE_LIBRARIES _target _interface_libs)
> > + if(KDE4_ENABLE_EXPERIMENTAL_LIB_EXPORT AND UNIX )# AND NOT APPLE)
> > + set_target_properties("${_target}" "${_interface_libs}")
> > + endif(KDE4_ENABLE_EXPE
On Tuesday 01 July 2008, Dirk Mueller wrote:
> On Friday 27 June 2008, Alexander Neundorf wrote:
> > > +macro (KDE4_TARGET_LINK_INTERFACE_LIBRARIES _target _interface_libs)
> > > + if(KDE4_ENABLE_EXPERIMENTAL_LIB_EXPORT AND UNIX )# AND NOT APPLE)
> > > + set_target_properties("${_target}"
39 matches
Mail list logo
