Steps to Reproduce:
Building libbluedevil from kdegraphics (2/11)
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.
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
# Force right path since implicit path would be trunk/KDE/playground-libs
# Might need to set this too, otherwise should save to $srcdir/playground-libs
dest-dir playground/libs # $srcdir/playground/libs
# Implicitly git
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)
Would have downloaded snapshot for libbluedevil
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
Build succeeded after 0 seconds.
Would have installed libbluedevil
Overall time for libbluedevil was 0 seconds.
<<< PACKAGES SUCCESSFULLY BUILT >>>
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:
use-modules playground/libs # will clone 'libs' from earlier and fixup path
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
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
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