This can be used as a run-time check later to ensure that kdesrc-build
finds compatible versions of its component modules (though that isn't
done yet).
This was the last remaining module embedded into the main script file,
so if we leave it here this completes the transition of modules out of
the main script.
This makes modularizing the build systems less annoying. I was surprised
that creating a class using a scalar variable instead of the bareword
works without tripping warnings about using references, but it works
just fine in testing here, test suite still passes.
This also required updating the test suite, which rather surprisingly
doesn't seem to need further modification (probably since the test-suite
includes kdesrc-build as a prerequisite, which sets up the @INC
modifications required).
This is probably the most dangerous change up to this point just because
a lot of modules descend from GitUpdate. I've run 'ack' on the source
tree just to make sure I didn't miss any renames from other modules at
this point. I've also built a kde-project module (which uses the new
ksb::Updater::Git indirectly) and it looks like everything still works
fine.
This PhaseList was one of the first modules added as part of the
refactoring effort, but I don't think it has ended up very useful (or at
least not as I had designed).
This move also required fixing ksb::BuildContext which had not 'use'd
ksb::PhaseList before, it had worked by accident.
Moving ksb::Util required splitting out script version tracking to a
separate module, as ksb::Util was using the previously-global versionNum
variable automatically.
Easy enough, seemed to work the first time. But I had to be careful to
remember to re-insert 'use IPC;' package declarations in each individual
module actually using these constants. It should be possible to remove
the ksb::IPC stuff by exporting the constants from the IPC.pm using
Exporter, but I'm not doing that at this point.
This is the lead-in to work which will eventually split out kdesrc-build
into component Perl modules and complete the modularization process.
This commit makes it possible for Perl to locate kdesrc-build modules
that are located in the XDG app-data directory (in case kdesrc-build is
installed), with a fallback to the kdesrc-build script directory (in
case kdesrc-build is run from a git checkout).
Although I am "modularizing" kdesrc-build, this is not an attempt to
split into CPAN-quality modules, rather we're just splitting into
separate files modules that are already conceptually separate
internally. At this point kdesrc-build will still be a single package
using as few dependencies as possible. However this will make it
possible to clone useful Perl modules if needed and will continue on the
path of de-cluttering the main script.
Feature seems to work in my testing, time to push out to master and verify it
doesn't break anything. I will also post the revised documentation to the
website.
If you don't like the idea of kdesrc-build adding a .xsession for you, then
you can set 'install-session-driver' to false in your kdesrc-buildrc.
My reading of the git-fetch manpage left me with the idea that adding
the '-t' (for --tag) option would additionally cause all tags to be
fetched from the given repository. The manpage doesn't actually say this
though, and git apparently instead downloads just the tags (and needed
objects), so this change has caused master branches around the
kdesrc-build world to stop updating. :(
The idea behind this had been to ensure that if the 'tag' option were
used in kdesrc-build that git would have the most up-to-date list of
tags available, but I guess we'll just have to go back to
crossing-our-fingers and hoping git already knows about the tag for now.
This allows for having a "shell setup" script usable everywhere and
managed by kdesrc-build, and yet still allowing the user to add their
own settings automatically.
This "shell setup" file is then used by the "session setup" script, also
managed by kdesrc-build.
I think we're getting close to something generically usable by all.
This implements the command line option mentioned in the last commit, to
allow for overwriting .xsession (and possibly .kde-env-master.sh, if it
exists).
Probably would still be a good idea to make a backup though.
Currently we install after printing out the various failure category
results.
There is a "--delete-my-settings" option that is mentioned to override
the file collision detection, but it's not actually implemented. We do
automatically ignore file collisions if the previous version was
installed by kdesrc-build, we use md5 digests to detect this case.
I will still need to rearrange the variables so that *only*
kdesrc-build-controlled changes are made in kde-env-master. E.g. KDEHOME
might be changed by the user... but then kdesrc-build will always
complain that it wants to overwrite it.
We're getting close though. :)
dfaure reinforced a point I was thinking after doing testing on my
system... the environment variable-setting portion of the script needs
to be factored out into its own script so that it can be sourced easily
from login profile setup, shell setup, etc. and not just used from the
xsession startup.
It's still not active (but the code is used in the test suite), will try
to work on that tomorrow assuming the sequel to "Perfect Storm" about to
strike here in DC leaves me with power...
I somehow missed the case of "branch option not ever set" by using the
getOption method to grab the git branch instead of the specific build
system "getBranch" method that had been used before. This led to build
errors trying to dereference an undefined variable.
My apologies for the trouble.
This makes the 'tag' option allow for checking out a given git tag for a
module (which is enforced by using refs/tags/$foo when passing to git).
Additionally, the 'revision' option has been adopted for git modules as
well, to allow for checking out any other git "tree-ish" that git
supports (i.e. anything supported by 'git checkout $foo').
Both options should leave the source directory in a detached HEAD state,
although kdesrc-build will adapt as necessary with each source update.
The auto-stashing is still attempted for both types, and a failure to
apply an auto-stashed change will cause the module to fail to build.
Ensure you're in a clean working directory if you want to avoid issues
due to this.
The test suite continues to pass (not that it's very extensive).
BUG:308493
FIXED-IN:1.16
Michael Pyne