In a previous commit I made a "large refactoring" that involved using
mixin classes to decide at runtime what build system or scm handler to
use for a given module.
In retrospect, using what is essentially a static class member to handle
a per-object decision was not my most impressive moment ever... this is
easily fixed by having specific scm() and buildSystem() members for each
Module instance, but does involve yet-more modification of code in lots
of places. :-/
Should be mostly the same as far as operation goes, but in this commit I
introduce a build system mixin similar to the scm handler mixin. There's
still more code that should be moved but we're getting closer to having
a simple build process where all the scm-specific stuff doesn't clutter
the main code with the equivalent of #ifdefs everywhere.
Add specific update classes (including a separate one for l10n support,
which probably doesn't work still...)
Still need to go further to split out this into easy-to-implement blocks
but the design is looking better.
$! should be treated like C's errno, which you can basically assume has
its value reset between libc or system calls. So, save the return value
before doing too much other work (to include I/O).
Now you can specify the private key to be passed to your SSH agent if
you forgot to run that before running kdesrc-build.
Proof-of-concept patch graciously provided by Ralf Jung.
BUG:284071
FIXED-IN:1.14.2
This is to help with refactoring a little bit. Right now there's at
least 3 separate backends being tracked:
1. git
2. svn
3. svn for l10n (kde-languages).
Ideally this will later be a generic method with "mixins" for the
backend-specific stuff.
Moving ksb::Phases to ksb::PhaseList gives room in the namespace for a
real ksb::Phase, although at this point my eventual "Phase" will
probably not be a separate class but instead a simple hash or something
in a dependency tree.
kde-baseapps must precede kate and konsole since kate/konsole are
logically under kde-baseapps. Thanks to dfaure for finally nailing down
the cause of this bug.
I will keep the bug open until I develop a way to detect and
automatically correct the module ordering should this happen again.
CCBUG:283127
If we check out kate before, kde-baseapps will refuse to be checked out,
because the directory will already exist and have stuff inside, which
leads to the error "[...] Please either remove the source directory yourself
and re-run this script [...]".
It makes sense that if there's no source code update that there should
be no effective change from the last KDE project database update on the
build list. So, implement bug 283026 to have --no-src give the same
semantics as --pretend for database updates.
BUG:283026
FIXED-IN:1.14.2
Dynamic languages got me again. ;) Perl couldn't find safe_system() at
runtime because it was looking in the wrong package, therefore simply
fully specify where the method is supposed to be.
Thanks Eike for the report.
BUG:283071
FIXED-IN:1.14.2
That is, when running with an rc file that is from the current directory
instead of the default ~/.kdesrc-buildrc. The --rc-file option was
probably affected by this as well.
Last time didn't get it apparently, so use a 2-pronged approach to
ensure we only run exit handlers once:
1. Use POSIX::_exit instead of the Perl exit builtin to ensure we skip
running the END { } Perl blocks that control our exit handler.
2. Record the PID when we start and have the exit handler only continue
if it's still the same PID.
This was brought to my attention by Ralf Jung as well (he ended up with
a lot of stray .kdesrc-build-data files from kdesrc-build trying to
record persistent data on shutdown to "current directory").
kdesrc-build still writes to the wrong location if you use a
./kdesrc-buildrc (note the order of . and /), but at least it only
writes the wrong location once now in my testing.
kdesrc-build gives a warning when the git repository has changed, but
makes it sound as if it will be trying to correct that. In reality it
should have already been fixed when kdesrc-build couldn't find a remote
that pointed to the correct repo.
Now that kdesrc-build will add the kde: alias and will convert
kde-projects URLs to be kde:-style, there should be no need for this
workaround.
CCMAIL:faure@kde.org
Ralf Jung noted to me in an email that the SAX-style parser used for the
KDE projects database does not handle the condition that the char
handler is called more than once for a tag, giving the akonadi
repository setting as an example of a problem for him.
And what do you know, a bug that's reproduceable here! I'm not sure why
the parser splits up the akonadi repo URL for both of us but this is my
fault so I suppose it doesn't matter. Ralf submitted an example fix,
which I simplified down to this. Thanks for the detailed report and
corrections to fix the issue!
CCMAIL:ralfjung-e@gmx.de
Now there should be no way to clone a KDE project git module without
having the origin URL use the preferred kde: format.
If you don't like this you can always set repository yourself in a
module (or module-set, git-repository-base should still work).
I just rediscovered why having singular options that don't accept
values, and combining those with extract_option_value(), is a bad idea
(Hint: It removes the command line entry following the option in
question).
That is, if the user permits it using --delete-my-patches, and only for
git clones at this point.
This should hopefully resolve bug 282367 (also frequently reported on
IRC ;)
BUG:282367
This doesn't so much actively search for things to delete. Instead it's
a required permission from the user to remove source directories (which
is similar to the remove-after-install option).
Right now this will only be used when trying to clone a git module and
the destination source directory already exists somehow, which has
happened for a lot of 1.14 early adopters due to old kde-baseapps
checkouts having a kate or konsole directory that conflict with where
kdesrc-build wants to put the current kate/konsole directories.
This commit makes the "module type" as determined from the
{repository,svn-server} options be the preferred method of determining
which scm tool to use.
This is required to allow nuking the source directory for old checkouts
in an upcoming commit (which was itself made an issue with the 1.14
release, that reorganized the on-disk layout, causing older kde-baseapps
checkouts with konsole/kate subdirs to conflict with the git
konsole/kate).
Michael Pyne
David Faure