Warning, /sdk/kdesrc-build/Internals.txt is written in an unsupported language. File is not indexed.

0001 Title: Module list construction
0003 An overview of the steps performed in constructing the module list:
0005 There are two parallel flows performed for module list construction
0007 1. Configuration file module list processing. The configuration file supports
0008 modules of various types along with module-sets. Modules of the kde-project
0009 type (available *only* from a module-set) can be converted later into 0, 1, or
0010 more git modules. Modules are formed into the list in the order given in the
0011 configuration file, but any modules implictly pulled in from the kde-project
0012 modules will be sorted appropriately by repo-metadata/dependencies.
0014 2. Modules can be directly specified on the command line. kde-projects modules
0015 can be forced by preceding the module name with a '+'.
0017 After processing command line module names, any modules that match a module
0018 (or module-set) given from the configuration file will have the configuration
0019 file version of that module spliced into the list to replace the command line
0020 one.
0022 So a graphical overview of configuration file modules
0024 >    svn, git, setA/git, setA/git, setA/git, setB/proj
0026 which is proj-expanded to form (for instance)
0028 >    svn, git, setA/git, setA/git, setA/git, setB/git, setB/git
0030 and is then filtered (respecting --resume-{from,after})
0032 >    setA/git, setA/git, setA/git, setB/git, setB/git
0034 (and even this leaves out some details, e.g. l10n).
0036 Command-line modules:
0038 kdesrc-build also constructs a list of command-line-passed modules. Since the
0039 module names are read before the configuration file is even named (let alone
0040 read) kdesrc-build has to hold onto the list until much later in
0041 initialization before it can really figure out what's going on with the
0042 command line. So the sequence looks more like:
0044 > nameA/??, nameB/??, +nameC/??, nameD/??
0046 Then + names are forced to be proj-type
0048 > nameA/??, nameB/??, nameC/proj, nameD/??
0050 From here we "splice" in configuration file modules that have matching names
0051 to modules from the command line.
0053 > nameA/??, nameB/git, nameC/proj, nameD/??
0055 Following this we run a filter pass to remove whole module-sets that we don't
0056 care about (as the applyModuleFilters function cares only about
0057 $module->name(). In this example nameA happened to match a module-set name
0058 only.
0060 > nameB/git, nameC/proj, nameD/??
0062 Finally we match and expand potential module-sets
0064 > nameB/git, nameC/proj, nameE/proj, nameF/proj
0066 Not only does this expansion try to splice in modules under a named
0067 module-set, but it forces each module that doesn't already have a type into
0068 having a 'proj' type but with a special "guessed name" annotation, which is
0069 used later for proj-expansion.
0071 At this point we should be at the same point as if there were no command-line
0072 modules, just before we expand kde-projects modules (yes, this means that the
0073 --resume-* flags are checked twice for this case). At this point there is a
0074 separate pass to ensure that all modules respect the --no-{src,build,etc.}
0075 options if they had been read from the command line, but that could probably
0076 be done at any time and still work just fine.
0078 One other nuance is that if _nameD/??_ above had *not* actually been part of a
0079 module-set and was also not the name of an existing kde-project module, then
0080 trying to proj-expand it would have resulted in an exception being thrown
0081 (this is where the check for unknown modules occurs).