[kopete-devel] kdenetwork - unnecessary find_package(KdepimLibs REQUIRED)

[Matt Rogers]

On Thursday 29 October 2009 08:59:12 Maciej Mrozowski wrote:
> On Wednesday 28 of October 2009 21:53:00 Urs Wolfer wrote:
> > On Wednesday 28 October 2009 18:47:38 Alexander Neundorf wrote:
> > > On Wednesday 28 October 2009, Matt Rogers wrote:
> > > > On Tuesday 27 October 2009 19:33:54 Maciej Mrozowski wrote:
> > > > > On Thursday 22 of October 2009 18:44:15 Alexander Neundorf wrote:
> >
> > [...]
> >
> > > > > - removed support for standalone krdc compilation - doesn't work
> > > > > well as it needs cmake modules from kdenework/cmake anyway.
> > >
> > > The krdc developers should comment on this.
> >
> > It's supposed to work... Probably it got broken with one of the recent
> >  chagnes (telepathy?). Anyway, I would like to keep this "feature" since
> > it makes it easier work with a IDE. It's not fundamental IMHO, but a nice
> > feature. I will try to fix it in a nice way ASAP (probably this
> > weekend?). If anyone has a better way to fix KRDC standalone build, feel
> > free to work on it.
> >
> > [...]
> 
> Well, apart from it mainly lacks cmake modules (that are provided by
>  toplevel kdenetwork/cmake, because they are shared), so making really
>  standalone build would require:
> - either duplicating them to project cmake subdirectory (and maybe some
> recently moved to kdelibs as well if one is paranoid about kdelibs
> compatibility) - the easiest, but leaves a little maintenance burden
> - moving most commonly used (or maybe all of them?) to kdelibs, after they
> pass some QA, and depend on particular kdelibs version at build time.
> 
> Alternative approach (rather feature request for cmake) - create mechanism
>  to fetch (and update) all cmake modules from some online repository, so
>  that there's no need to depend on particular kdelibs version just to have
>  cmake modules available to use.
> 
> > > > I dislike the STREQUAL stuff. if (NOT INSIDE_KDENETWORK) is about a
> > > > bazillion times easier to read. I'd rather use kdenetwork_SOURCE_DIR
> > > > or whatever it is that gets generated by the "project(kdenetwork)"
> > > > call. Seriously, does having an extra variable actually add that
> > > > significant of a cost?
> 
> If it was up to me, if any, I'd prefer STREQUAL way as it is the most
>  generic and will work like everywhere. It does not need module_SOURCE_DIR
>  nor any other external variables to be defined, thus it can serve as a
>  good copy/paste example to be used elsewhere.

I don't care as long as the use case I mention below can still be supported.

> I think the best way of getting just some subdirectory to build/develop is
>  to fetch whole module (like kdenetwork), then remove every subdir that is
>  not 'cmake' and not 'krdc' for instance. It will be 'standalone' in terms
>  it won't build unnecessary stuff, yet it doesn't need separate cmake
>  codepaths to get it done (easier maintenance, no duplicated code - win-win
>  if you ask me).
> 

Except that it doesn't work for the more common use case of using git-svn to 
mirror a single directory, so it's not the best way for me (and others). That 
was what the whole INSIDE_KDENETWORK thing was trying to address, if we can 
use the STREQUAL way or some other more generic way, then whatever, as long as 
I can still use it like I want.
-- 
Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20091029/ba0fde58/attachment-0001.sig