Version: Subversion (using Devel) OS: Linux When trying to compile strigi from a fresh new pulled repository I got the following cmake errors: -- No CMakeLists.txt found in libstreams -- No CMakeLists.txt found in libstreamanalyzer -- No CMakeLists.txt found in strigiutils -- No CMakeLists.txt found in strigidaemon -- No CMakeLists.txt found in strigiclient Since those modules now constitute separated repository, is it expected they also continue inside strigi ? If yes (as two alternatives of building strigi) shouldn't kdesrc-build somehow handle these two alternatives ? Reproducible: Always Steps to Reproduce: - remove all strigi source folders - remove all strigi build folders - run ./kdesrc-build strigi
For now you'll have to build the individual subrepositories of strigi. This is easiest done by using the trunk version of kdesrc-build, and consulting the changes made to kdesrc-buildrc-sample to support a strigi module-set. Supporting the current layout of the strigi respository currently would require adding git submodule support apparently, and git is hard enough to use from a script as it is. This will probably be rendered moot by the upcoming kde_projects.xml file which is being developed, which kdesrc-build would be able to use to group strigi for you, among others.
Hi again, Talking to krop at #kde-devel, he ended up with a patch in strigi/CMakeLists.txt to automatically pull strigi git submodules when a cmake define (STRIGI_SYNC_SUBMODULES) is true. In addition, if building strigi as a monolitic lib *or* separated modules are two mutually excludent alternatives, should not kdesrc-buildrc-sample adopt just one of them ? If yes *and* was choosen to build strigi monolitic we should add the following lines just after the strigi module-set definition: module strigi cmake-options -DSTRIGI_SYNC_SUBMODULES=TRUE end module I'm already using the trunk version of kdesrc-build and kdesrc-buildrc-sample. Thanks in advance,
Yes, I would go with just building the individual modules at this point as it is better supported (although I've moved them into a separate module-set). I'm testing the result now, I'll commit if it seems to work ok.
SVN commit 1210570 by mpyne: Only use one style of strigi module handling. Right now that means just grouping the modules into their own module set, and leaving out the strigi supermodule. At some point I may allow module-sets to have their own names so that you can do "kdesrc-build strigi" from the command line, but for now this will have to work. BUG:261638 M +9 -1 kdesrc-buildrc-sample WebSVN link: http://websvn.kde.org/?view=rev&revision=1210570
> Yes, I would go with just building the individual modules at this point as it is better supported Nope, building the subdirs individually is broken, because the subdirs expect the version stuff from strigi's CMakeLists.txt to be set.
SVN commit 1210660 by mpyne: Actually, prefer single strigi module to individual submodules. kdepepo tells me that the submodules /do/ require some of the special variables from their supermodule (which makes sense). Turns out I built-in a way a long time ago to force CMake to run when needed, so let's just go that route. This should hopefully complete the support needed for strigi for good until kdesrc-build uses the projects.xml that is under development. BUG:261638 CCMAIL:cgiboudeaux@gmail.com M +7 -2 kdesrc-buildrc-sample WebSVN link: http://websvn.kde.org/?view=rev&revision=1210660