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.
The new-style atexit implementation used /also/ propagates across fork
calls, so every child which is forked ends up calling finish(). This is
marginally annoying except for Subversion modules, where the
'module_has_conflict' check run by log_command() technically involves a
forked child for the implementation.
Since the abnormal-end finish that gets run by atexit takes priority
over the result code from module_has_conflict it appears that there's
always a conflict.
Instead, just make sure that finish() is only called for real from the
process that installed the handler in the first place.
Using dclone() on passed in modules in updateModulePhases causes the
Module's buildContext to also be cloned, but the function calling
updateModulePhases is working on an entirely different BuildContext, and
this inconsistency can cause problems in the newly-introduced
lookupModule function.
Since there's no reason to protect the input modules, just don't bother
using dclone.
It is sometimes needed to be able to determine information about a
module based just on its module name. It used to be the module name was
all the information that a function had, and so it was sufficient by
definition, but with Module objects that is not always the case.
To allow for finding the matching Module for a module name add a search
function to the BuildContext.
Normally kdesrc-build uses the 'global' pseudo-module in order to store
config data which is generic across different build modules. To be able
to move "get_option" to Module we need a way to handle that, and to
allow methods to operate on either generic or specific options we need
to ensure that whatever method is used has a common interface to Module.
The method I chose is to have a kind of parallel Module created which is
held by the BuildContext, but not in the normal list of Modules. This
commit creates that globalModule and adds an accessor for it.
I thought I had fixed this a couple of weeks ago on this branch, but we
don't need to check for pretend mode in download_file, as the only user
of download_file does the check for us, and might actually need to
download the XML file when pretending.
get_fullpath's type param should be either 'source' or 'build', not
'source-dir'. This unintentionally did the right thing since
get_fullpath only checked for 'build', but a revised implementation
caught this error.
kdesrc-build has supported emailing error messages for some time, at the
conclusion of the build process. There is no easier way to "modularize"
this code than to elide it completely, and given that no one seemed to
use it in the brief poll I conducted, I've removed it.
This method is intended to eventually replace the global get_fullpath.
I'd fold get_module_path_info into that as well except that it is used
separately for svn checkouts into the right directory.
There is discussion about removing the weekly generation of Subversion
snapshots at this point, and with the migration of services off of
Subversion, using snapshots doesn't help reduce load on the svn.kde.org
servers that much (if at all), and it's easier to port code that doesn't
exist, so goodbye.
This also removes the recently-added svn->git migration checker, which I
haven't ever seen actually come across an svn module even on my lazy old
source repo, so I can only assume the check is not actually correct.
Things like assert_isa will be needed to help ensure that dynamic object
handling is still tractable since we don't get C++-style static type
checking. This also gives me an opportunity to move make_exception to
its own package for further refactoring.
One thing nice about the last change is that now handle_build knows what
module set (if any) a given module is a part of, and can display that
while building so the user knows where part of the rc file to edit.
This allows the handle_build subroutine to use the Module objects
directly instead of just working with module names. Still a lot that has
to happen to make everything work cleanly, but modules should continue
to build.
One area that needs fixing is to make handle_{install,uninstall} call
the modified filter_l10n_module_list correctly, which is a minor point
at this point as handle_install called from build_module as normal
should still work correctly.
Forever now there has been two separate main execution sequences:
1. Before the lock is taken. Failure here means plain exit() should be
called.
2. After the lock is taken, whereupon finish() must be called to remove
the lock.
Now we just always have an atexit-like facility available, so we add a
finish handler when appropriate, and pare down to one exception handler.
This is required to be able to use the stringify overload for modules,
and matches how list_has previously worked (when everything was a
string in kdesrc-build).
Michael Pyne