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

Alexander Neundorf neundorf at kde.org
Thu Oct 29 19:06:06 CET 2009


On Thursday 29 October 2009, 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.

Which modules are that ?
Maybe they are used only by krdc ?

> 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.

Hmm, would that be different from installing them along with kdelibs ?
I mean from the compatibility POV...

We could download them from somewhere using wget or file(DOWNLOAD ...), but 
this would place the compatibility burden on that remote network repository.

> > > > 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.

Either STREQUAL or the <project>_SOURCE_DIR, from my POV both are ok.

> I think the best way of getting just some subdirectory to build/develop is
> to fetch whole module (like kdenetwork), 

You could also check out kdenetwork non-recursively and then only update 
cmake/ and krdc/

Alex


More information about the Kde-buildsystem mailing list