Subversion 1.7 requires a manual upgrade of the working copy in order to
do anything (even to run svn status). Luckily there's an error message
ID for this case so it's not too hard to grep for situations where this
is necessary.
One problematic element is that since even 'svn info' doesn't work in
this situation, --pretend mode doesn't work either for svn modules. For
now I just throw an exception (after the check) when in pretend mode so
avoid follow-on useless error messages.
It was interesting how I still had the old 1.6.17 for so long -- turns
out I had forgot to rename my subversion selector asking for unstable
versions in Gentoo (at some point their package name changed from
dev-util/subversion to dev-vcs/subversion, which I didn't keep up with).
Thanks Will Stephenson for the bug report.
BUG:304415
Unfortunately I was not able to split out moving safe_make and
run_make_command with the actual implementation of this option
after-the-fact. Whoops.
This should implement support for a custom build command (and custom
install command, assuming the install can be performed by adding
'install' to the command line).
Hopefully that will be sufficient for 'ninja' or other buildsystems.
Note that this only changes the *build* command, the other parts of the
build system still needs to be supported in kdesrc-build (for now,
custom build systems probably wouldn't be too hard to implement if
necessary).
Assuming your proposed command is available in PATH and can be called
like make, doing something like this should suffice:
module (or module-set) foo
custom-build-command ninja
end module (or module-set)
BUG:303692
My code to "add inherent dependencies" was meant to have things like
kde/kdelibs/* automatically depend on kde/kdelibs, but it ended up
making module names that have no slash whatsoever depend on itself.
Reported by Sune when he couldn't compile calligra (presumably on the
command line). I will try to add to test suite in a bit.
Notably, a configuration is now actually required. I will try to arrange
later for a built-in basic configuration to allow kde-projects modules
to work even with no configuration at all.
This helps minimize a long-problematic source of duplication. Of course
there is still kdesrc-build-setup to deal with...
It was difficult to see the error message until I thought to remove the
'clearScreen' call before throwing the "dialog canceled" exception, but
the cause of bug 300911 (Setup quits unexpectedly when choosing a custom
install directory) is due to the dialog(1) command failing when it
couldn't create a window big enough for the directory selector.
Apparently the "height" parameter does not include all the curses
window decoration.
(Fixed-in flag reflects the kdesrc-build version)
BUG:300911
FIXED-IN:1.16
Torgny Nyblom has been working on a revision of the dependency-data
format to support using that information for
Jenkins/continuous-integration testing.
Right now we don't do much with it (perhaps later we can ensure that
branches are correct when building to keep from avoidable errors), but
this change should support reading in the new format.
Older kdesrc-build versions will throw an exception but continue on
without dependency-reordering and hopefully without further error.
CCMAIL:nyblom@kde.org
This change allows a KDE Project module to depend on a KDE Project
module that is its immediate parent. For example,
kde/kdelibs/nepomuk-core would depend on kde/kdelibs if both are present
in the build, to ensure that kdelibs is cloned before nepomuk-core. To
be fully, absolutely correct we should probably depend on /any/ parent
present in the build, not just the immediate one. Maybe for later...
This makes existing dependency-data for kde-baseapps/{,konsole,kate}
redundant although I will leave it there for the benefit of other
projects that might be using it.
I use 'framework' kind of liberally in the script to mean base/essential
libraries for KDE development, but it has understandably been confused
with the frameworks branch of kdelibs. Rename.
Perl seems to assume that a lowercase function name that is not *known*
to be a function defined in the current package might be a filehandle or
some kind of other future reserved word.
e.g. with "print foo ($message)"
Perl thinks you're trying to send $message to the filehandle foo if foo
wasn't defined in the current package (even if it's imported from
another module).
To fix this we make the function start with a capital letter (to fix the
potential reserved word warning from the last commit changing colorizer
name), and always reference the full package when using the subroutine
from outside of ksb::Debug.
Wanting to get at least some testing done of git-clone functionality
given the large refactor that I have rebased into master, I ended up
adding a simple test to checkout kde-build-metadata. (Testing the
refactored code on existing git checkouts is the easy part for me)
As it turned out, that test caught a different bug (kde-build-metadata
should not use the global branch option).
A couple of git tests were passing when the test suite was run from a
git checkout and failing when not. This was due to an underlying
errorneous assumption.
This commit fixes that assumption by making a new
git checkout, and also changes to the temporary directory setup for the
test at the start to hopefully prevent other tests from passing when
they shouldn't.
BUG:299579
FIXED-IN:1.15.1
I had thought I had already moved absPathToExecutable into ksb::Util,
but as it turns out I had not done so quite yet.
This caused my bugfix for bug 299577 to instead cause a crash, sorry
about that. :(
BUG:299577
qmake isn't always named 'qmake'. kdesrc-build searches for qmake before
it runs to avoid having to take a long time to fail to build dozens of
modules, but should search for the same names looked for by the FindQt4
cmake check.
In addition to correcting the check, I've also fixed the usage of
'qmake' in the QMakeBuildSystem. Thanks for the prompt bug report! (And
please re-open if this fails for you, it's a bit more difficult for me
to thoroughly test)
BUG:299577
FIXED-IN:1.15.1
Specifying a job number by default makes life harder for people who
use the MAKEFLAGS environment variable (because the number if
processors changes dynamically due to distcc or icecc, for example).
It is safer to simply let the user decide to override make-options in
his RC file (this is sufficiently documented in the sample RC file and
in docbook) or use $MAKEFLAGS.
Reviewed-by: mpyne
When setting up a local remote-tracking branch (either on clone or when
the user chooses a different branch in the rc file), kdesrc-build has
preferred a '$remoteName-$branchName' naming convention to try to avoid
stepping on user's existing branches.
In reality most users do not use local branches, and those that do would
(according to feedback I've received) prefer the local and remote branch
names to be the same as per git practice basically everywhere.
Since it's easy enough to check that the local branch doesn't already
exist before creating it, just do that and drop the remote name from the
created branch name.
BUG:294347
FIXED-IN:1.15
Michael Pyne
Script Kiddy
Raphael Kubo da Costa
Yuri Chornoivan
Burkhard Lück