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).
Modularization continues. A couple of functions actually really only
need to deal with the string value of the name. These functions have
been changed to accept the name into a param named "moduleName" since
I'm trying to ensure once this is done that '$module' will always
actually be a Module.
Note this uses the 2-argument getOption introduced in the last commit.
Turns out that I had the great idea for a way to grab *just* a given
module's named option (if any) a long time ago. Unfortunately I had
added it directly to get_module using an optional third parameter and so
forgot about it later and reimplemented it.
I discovered this in the process of trying to complete modularization of
Modules in svn_module_url. For now I've ported that function to
Module::getOption and removed usage of get_module_option().
This ended up having to be mostly at once due to the kind of chain
effect that came from altering functions like get_subdir_path,
get_source_dir, etc., but this commit changes most module-handling
functions to work instead on Module objects.
I've been able to get through a normal --pretend run, properly git-clone
a module and build/install it, properly svn co and svn update modules
and install them, but that's the extent of my testing at this point. The
test cases themselves have not been checked yet sadly, surely many of
them need slight touch-ups to still pass.
Still some small functions to go, but getting closer to where I can
start moving more functions into appropriate classes/modules, and then
from /there/ start factoring out qt-copy specific code, kdelibs-specific
code, etc. into their own modules. I'm thinking some kind of mixin
approach but we'll see.
I went the wrong way with my last commit. At normal program termination,
remove the abnormal termination handler and then manually make the right
exit call.
Michael Pyne
Raphael Kubo da Costa
David Faure
Script Kiddy
Raphael Kubo da Costa