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
This partially implements bug 308493. To fully implement it will be
required to handle the case of an already-checked-out module (though
prepatory work is already complete).
CCBUG:308493
To support git tags we need to take different semantic actions (as
checking-out a git tag leaves you in a detached-HEAD state where
git-{pull,merge,rebase} don't apply). To prepare for having different
methods for these different semantics I'm factoring out the git-remote
setup into a separate function, and removing the needless support for
lists of possibilities. Nowadays kdesrc-build only cares about origin,
though if you want to bring your own remote that's fine, kdesrc-build
will find it.
kdesrc-build has long supported using a file '.refresh-me' in a build
directory as a flag to treat a module being built as if the
'--refresh-build' command line option was passed for that module.
As suggested in my last commit message, this commit will automatically
create that file if the configure/build-system-setup phase of a module
build fails. This way even if I choose wrong on which filename to look
for to determine a successful build, there will still be a way for
kdesrc-build to easily tell that it should start all over next time.
We used to use "Makefile" for the KDE/CMake build system to determine
when CMake was successfully run, but the commit to allow for
custom-build-commands replaced that with CMakeCache.txt.
This choice was incorrect, as CMakeCache.txt is always generated, even
if CMake fails. cmake_install.cmake seems to be a better choice (I've
confirmed it's generated on success with both ninja and Makefile
generators).
It's probably still a good idea to explicitly touch .refresh-me in the
build directory if the configure phase fails. I leave the build
directory intact if configure phase fails to allow for "post disaster
investigation" but we should always re-run configure phase in this event
on the next kdesrc-build run.
A few minor related changes are included. E.g. we actually want to pass
along blank lines, so remove that check (which didn't work anyways as \n
was still present).
We replace that with a simple filter in the template installation
process to allow there to be source lines in the base template that
don't get passed to the installed result. This allows for shell script
that prevents running the full command suite in the base without
affecting the installed script.
It is required to be able to actually run the base script as the "set
-u" check for unset variables doesn't work when "set -n" (syntax check)
is in use. These set commands can be passed directly to /bin/sh to have
them in effect when the script starts (and are both part of POSIX and
seem to work even with busybox sh).
Additionally, the path_add function needs to actually check for unset
variables now. Luckily there is existing Bourne shell syntax for that.
The observant reviewer will note that the testsuite does not currently
pass because there is a mispeled lib_suffix in the base, that will be
fixed in the next commit.
Michael Pyne
T.C. Hollingsworth
Script Kiddy