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 _______________________________________________ kopete-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kopete-devel
