Ever since kde-projects XML support was added you could (in theory) use
the syntax +modulename on the command line to force kdesrc-build to
interpret that module as an XML module.
Later a filter was added to avoid building modules on typos, which also
trapped all +modules.
Now if you use +module on the command line kdesrc-build will keep
processing it, and catch misspellings later or build the whole module if
it's actually defined in kde_projects.xml.
kdegraphics actually needs it as of this writing since it is marked as
inactive in projects.kde.org. Even if it is made active, kdegraphics's
repo should not be built in conjunction with its logical children's
repos.
As suggested by dfaure and at least one other person whose name escapes
me now, with all the modules available in git.kde.org it makes sense for
their on-disk layout to match the hierarchical organization given in
projects.kde.org, so kdesrc-build now does that.
If there's a big hub-bub about this I can make it optional, however I
think it should hopefully not be too hard to adjust to. A later commit
will add auto-migration of old source/build dirs because I love you all.
CCMAIL:dfaure@kde.org
Modules like kdegraphics are both the ancestor of a group of logical
child modules, and repos in their own right. kdegraphics is marked as
non-active since it's repo just exists to allow for building the
subprojects, but that means kdesrc-build won't build it.
So, allow for specifying modules *under* a given module. This allows for
a syntax as follows to work:
module-set kdegraphics-set
repository kde-projects
use-modules kdegraphics/libs kdegraphics/*
end module-set
(The kdegraphics/libs forces those modules to be added first. They will
not be readded by the later kdegraphics/*)
This doesn't allow for resuming at this point but if it's not too hard
to add and there's interest from the sysadmins I can look into that too.
Either way it should allow for a load reduction on git.kde.org (or
rather, anongit.kde.org), but this only works for modules accessed
through the projects.kde.org XML database (i.e. repository kde-projects
in your module-set)
Trying to build a module-in-migration gives a confusing error message in
master, and gives an even-more-confusing "successfully did nothing" type
of response in the modularize branch.
Look for empty XML module expansions and give a warning message if they
don't result in anything to avoid that.
The test suite now works again. One test related to the kde-languages
option was removed since I expect that the feature is not ready, but all
other tests still pass.
File::Path even includes the "pruning under a directory" feature that
dfaure had requested to be added so long ago. Would have been a lot
easier to implement that if I had known about File::Path! ;)
The global package_opts hash holding all option values for all modules
has been moved to ksb::BuildContext. This should start making it easier
to keep unit tests working, avoid long-term action-at-a-distance, and
all the other reasons why we avoid global variables.
That is now one less user of global package_opts. In fact I think it's
about ready to finally go. Next step after that would be splitting out
the various update/build/etc. phases into usefully modularized bits.
It's a bit of a chicken and egg problem, otherwise. Well, of course one
can use kdesrc-build uninstalled, but this way an automated build host
can just start with "./kdesrc-build/kdesrc-build kdesrc-build" to ensure
it's up-to-date :-)
Now there are precious few instances of the global package_opts variable
lying about. Most everything has been moved to appropriate spots in the
BuildContext or Module classes (or can be trivially moved there).
Next on the list is persistent option refactoring.
At this point the only functions that reference the global package_opts
are the option handling functions (both normal and persistent options)
which can be factored into the build context and Module.
The functionality itself has mostly been moved to BuildContext, although
the output functions are still part of the script proper. This required
a few changes, but less than I thought, and seems to work well so far.
Still remaining is the failed module list handling which will require a
more invasive change, and then option handling itself (both in-program
and persistent).
This has the possibility of breaking filter_l10n_module_list and
therefore kde-languages handling, at least for now. This is in support
of getting rid of package_opts.
Next major step on my roadmap for a more modular kdesrc-build is to be
rid of the %package_opts global variable of set options. This commit
removes a direct usage by removing a default option assignment in favor
of creating a Module first (which will at some point set its own default
options), and then changing set options from there.
I thought I had been rid of the corrupt XML detector awhile ago by
simply always overwriting the XML when kdesrc-build runs/downloads, but
perhaps I hadn't merged it to the modularize branch.
kdesrc-build has always had a two-level hierarchy for module options
(where options are searched from any module-specific data first, then
the shared 'global' module).
I've tried to modularize this by making the common build context have a
'globalModule' accessor available, but it's more generic just to make
the build context itself act as a Module for code that simply needs to
run ->getOption.
So far it actually seems to work fairly well.
rc file loading is moved to BuildContext. Seems to be a bug with calling
loadRcFile twice when I add svn-server and repository to an existing svn
module, but other than that things appear to work well.
This supports moving module_scm_type's implementation completely into
Module, so that is done as well. In addition some more runtime class
type checks are added.
The check_for_module_config procedure was used to ensure that the user
actually meant to build a module given on the command line that doesn't
match any in the rc file.
This is currently superseded by a separate check that doesn't allow
*any* module to build if it's not present in the rc file. My intention
is to allow this check to pass if the module matches either the internal
built-in config (which I haven't implemented yet) or the
kde_projects.xml (which I haven't implemented the special case for).
Either way this check will remain redundant, so remove it.
A couple of shell scripts to identify subroutines and the amount of time
they were used came up with these functions which are confirmed not to
be used anywhere. Sayonara.
Post-build email error reporting was removed in commit e7e8930 but not
all code needed to support that feature had been removed. This is now
rectified.
default_module_branch was only effectively used for setting a default
branch option for a module that had no user-set options. However, no
default branch is typically required to be separately set (svn based
branch on the checkout path which would be correct anyways, and we
always clone master first for git anyways).
Removing this method makes it easier to refactor, and also frees up some
more dead code on top (get_svn_branch).
Michael Pyne
Raphael Kubo da Costa
David Faure
Script Kiddy