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
This is also fixed now in the KDE build metadata but might as well have
it right here too.
Thanks to Jan Hackel for the report and diagnosis.
BUG:298401
This reverts commit 089edc6a73.
Although auto-grouping is a nice easy way to get approximately right
dependency ordering, it doesn't work in all situations.
The "Best" thing would be to only sort within kde-project modules (as
expanded) but for now just back out this commit so I don't break
customized rc-files.
BUG:297847
Valery Yundin has kindly submitted a patch (including documentation!)
resurrecting the old "use-stable-kde" option to allow for defaulting
kde-projects modules to the stable branch (if defined for that module).
This should track with changes to the stable branch as defined, so it
would be a good way to track the "not quite bleeding-edge" of
development.
A hearty thanks to Valery for making up a patch and then adapting it to
make use of the old use-stable-kde option.
BUG:297357
FIXED-IN:1.15
And with that being completed, remove the BEGIN { } hack to force
debugging/pretend functions to be parsed first.
This did require renaming clr to colorize, and then to ksb_clr, since
Perl complains about the first two names being possibly reserved words
in the future.
In the act of removing a now-extraneous method prototype in the next
patch I noticed that I had not fixed ksb::Debug's import method to work
with method that had no prototype.
"Don't Repeat Yourself" being a good idea and all, I refactored both
methods to a common one that works on everything.
log_command supports calling an internal subroutine instead of
exec()'ing a new process in the logged child. The subroutine is
identified by name.
With the move of log_command to ksb::Util, log_command now assumes that
the named function will be found in ksb::Util instead of the main
package, but none of the users of this feature were ported over.
This led to bug 297158 (kdesrc-build fails to --refresh-build a module)
since the 'prune_under_directory' routine used to refresh the build
directory wasn't being called by log_command anymore.
Thanks to Kevin Lyles for the prompt and informative report!
I've added a (very simple) test case to ensure the subroutines can be
called at all (a test which now passes).
BUG:297158
FIXED-IN:1.15
After doing the same for git support the non-modular code base might be almost
tractable.
In addition to the movement of code I also added a testcase for KDE SVN SSL
signature installation.
This occurs before dependency resolution (so that the dependency metadata is
still "preferred"), and is a simplistic dependency sorting technique.
This prevents dependency-data metadata from having to become insanely
complicated to ensure that each module depends on kdelibs (since kdelibs can't
simply be special-cased to be "dependency #2" as it has a lot of dependencies
itself on kdesupport/ modules like automoc.
So, we instead group modules after dependency resolution into:
qt (right now, just the projects.kde.org one, not any generic Qt)
kdesupport/*
kdelibs
projects.kde.org modules not already determined
other modules
It is possible to override the tier you end up at by setting the
"ordering-tier" option for that module to an integer.
E.g. for git command output when we haven't quite cloned the module for the
first time you're likely to get undef for the output (since the command will
just fail). Check for that.
If you (for whatever reason) don't have things like cmake installed before
trying to run a full build you'll just spend a lot of time to eventually figure
out that kdesrc-build wasn't able to build anything.
Now we can (optionally!) skip the build process entirely if "essential"
programs do not seem to be available before running the build. Each build
system type is able to determine which programs are considered essential.
Note that if 'qmake' is the only holdup then we don't complain if we seem to be
building Qt or if we're in pretend mode (since it's certainly possible to fool
build system detection when in pretend mode). If qmake is really missing the
user /should/ just find out when they run without --pretend (since then Qt
should show up amongst the build-modules' build systems).
BUG:263936
FIXED-IN:1.15
I'm apparently pretty stupid at POSIX... I thought that holding onto an opened
file handle and then allowing a separate library to download a file to the same
name as the filename for that opened file handle would mean I could use that
file handle to read from later... nope. Instead just re-open the file manually
after the download has completed.
This allows log_command users to not have to much about with LC_ALL or friends
themselves.
To avoid parameter bloat a hash reference of options to use is now passed as
the final parameter.
The idea is going to be to have the renamed filter_program_output be the one
way kdesrc-build handles reading program output, so that I can move all the
locale-disabling code strewn about the code base to just one function and
hopefully handle everything related to disabling message translation while
passing command line arguments correctly.
As opposed to having Test::More figure it out automagically (which I was only
doing because changing the number of tests expected with a changing test suite
is more work than I really need).
Right now there's only one user of this function (safe_run_cmake), but that
subroutine is itself already too large for me to consider inlining it.
I did at least remove the prototype for the subroutine as I moved it however.
The new Bzr support exposed that getOption(foo, 'module') will return undef if
the module doesn't have an option foo (instead of '' like normal). This causes
the test suite to give some warnings that aren't seen in normal code execution.
To fix we just use an empty string as the repository if getOption() returns
undef.
Michael Pyne
Raphael Kubo da Costa
Burkhard Lück
Valery Yundin