| Summary: | Wrong module name in output: "Building libbluedevil from kdegraphics (2/11)" | ||
|---|---|---|---|
| Product: | [Developer tools] kdesrc-build | Reporter: | David Faure <faure> |
| Component: | general | Assignee: | Michael Pyne <mpyne> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | http://commits.kde.org/kdesrc-build/5d638acab096f17dd1d136868e674d36eed6f21e | Version Fixed In: | |
| Sentry Crash Report: | |||
| Attachments: |
kdesrc-buildrc which triggers the problem
kdesrc-build which actually triggers the problem |
||
Don't have time to track down tonight (the "from $foo" text is supposed to occur only for module-sets with a name, like "module-set kdegraphics"). But to answer your other question, svn syntax is basically any plain module without a "repository" option. git/bzr can be selected using "repository". module-set gives a constructed repository option based on the repository/git-repository-base (as appropriate) and the use-modules option. You would want to avoid having the two modules end up with the same name, so perhaps something like module playground-libs # Force right path since implicit path would be trunk/KDE/playground-libs module-base-path trunk/playground/libs # Might need to set this too, otherwise should save to $srcdir/playground-libs dest-dir playground/libs # $srcdir/playground/libs end module # Implicitly git module-set repository kde-projects use-modules playground/libs end module-set Could you attach the full kdesrc-buildrc used for this? I can't reproduce, but I would guess that it comes down to one of: 1. A parser coding error in parse_moduleset (the only code that uses the Module::setModuleSet function call that assigns a module set name). 2. Some other kind of error where the 'module-set' option accidentally gets read in for a module itself (i.e. after the parse phase, this is the internal option name backing the module->module-set relationship). Created attachment 80805 [details]
kdesrc-buildrc which triggers the problem
Created attachment 80944 [details] kdesrc-build which actually triggers the problem I was able to reproduce with this rc-file, adapted to fix the SVN syntax for playground/libs and the git syntax for playground/libs (i.e. to make it a module-set). With this rc file we get the wrong module-set name, despite the fact that I specified a different module-set name! $ kdesrc-build -p --rc-file bug-kdesrc-buildrc playground/libs In fact even $ kdesrc-build -p --rc-file bug-kdesrc-buildrc libbluedevil is enough to show the problem: Would have created /d/kde/src/t * Downloading projects.kde.org project database (will not be saved in pretend mode)... Building libbluedevil from kdegraphics (1/1) Cloning libbluedevil Would have downloaded snapshot for libbluedevil http://anongit.kde.org/libbluedevil/libbluedevil-latest.tar.gz Source update complete for libbluedevil: 1 file affected. Preparing build system for libbluedevil. Would have cleaned build system for libbluedevil Would have created /d/kde/build/t/playground/libs/libbluedevil Running cmake... Compiling... Build succeeded after 0 seconds. Installing libbluedevil Would have installed libbluedevil Overall time for libbluedevil was 0 seconds. <<< PACKAGES SUCCESSFULLY BUILT >>> libbluedevil I mentioned this on IRC, but for posterity's sake the cause of the issue is essentially that kdesrc-build only records a module by the most-specific path component. E.g. kdegraphics/libs is stored as 'libs' to allow one to easily override module options for it later. (Though this is intended for actual modules like kdemultimedia/juk instead of a shorthand for virtual groups).
A small testcase should be:
global
end global
module-set kdegraphics
repository kde-projects
use-modules kdegraphics/libs
end module-set
...
module-set playground-libs
repository kde-projects
use-modules playground/libs # will clone 'libs' from earlier and fixup path
end module-set
Git commit 5d638acab096f17dd1d136868e674d36eed6f21e by Michael Pyne. Committed on 23/07/2013 at 22:58. Pushed by mpyne into branch 'fix-recursing'. kde-projects: Accurately track parent module set. This is unfortunately a giant change, as all of the functionality that is encompassed into module-sets currently had to migrate over to multiple separate classes, including the new ksb::ModuleSet class and subclasses. This was a long-overdue change, however, and should allow for accurately tracking a source module-set for a given module. On the other hand this migration of logic has made it easier to understand each of the individual pieces where they stand (e.g. there is no longer a separate expandXMLModules and expandModuleSets). In addition we can properly handle ignore-modules with wildcards just as we do with use-modules (they even use the same matching logic) which means that it is safe to integrate this into master (assuming no extra boogs get added, of course). This will also help with fixing some of the extant module-selection bugs (321883, 299415). Related: bug 321667 M +151 -403 kdesrc-build M +67 -1 modules/ksb/BuildContext.pm M +52 -19 modules/ksb/KDEXMLReader.pm M +4 -2 modules/ksb/Module.pm A +182 -0 modules/ksb/ModuleSet.pm A +222 -0 modules/ksb/ModuleSet/KDEProjects.pm A +33 -0 modules/ksb/ModuleSet/Null.pm http://commits.kde.org/kdesrc-build/5d638acab096f17dd1d136868e674d36eed6f21e |
module-set use-modules playground/libs repository kde-projects end module-set Reproducible: Always Steps to Reproduce: kdesrc-build playground/libs Actual Results: Building libbluedevil from kdegraphics (2/11) Expected Results: Building libbluedevil from playground/libs (2/11) No idea where the "kdegraphics" comes from :-) Additional question: how do I build both playground/libs from SVN and from git? I'm still very confused by the kdesrc-build syntax since the svn+git mix.