Bug 321275 - Wrong module name in output: "Building libbluedevil from kdegraphics (2/11)"
Summary: Wrong module name in output: "Building libbluedevil from kdegraphics (2/11)"
Status: RESOLVED FIXED
Alias: None
Product: kdesrc-build
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Michael Pyne
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-17 14:46 UTC by David Faure
Modified: 2013-07-24 04:28 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
kdesrc-buildrc which triggers the problem (9.05 KB, text/plain)
2013-06-27 10:51 UTC, David Faure
Details
kdesrc-build which actually triggers the problem (9.18 KB, text/plain)
2013-07-04 16:29 UTC, Michael Pyne
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Faure 2013-06-17 14:46:04 UTC
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.
Comment 1 Michael Pyne 2013-06-18 02:55:06 UTC
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
Comment 2 Michael Pyne 2013-06-20 02:48:04 UTC
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).
Comment 3 David Faure 2013-06-27 10:51:38 UTC
Created attachment 80805 [details]
kdesrc-buildrc which triggers the problem
Comment 4 Michael Pyne 2013-07-04 16:29:01 UTC
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
Comment 5 Michael Pyne 2013-07-06 01:23:23 UTC
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
Comment 6 Michael Pyne 2013-07-24 04:28:12 UTC
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