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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
