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.
Commit 91f312e removed the required use File::Temp line for tempfile(), but
that function a) didn't move out of package main, and b) wasn't re-added to any
other package in kdesrc-build anyways (i.e. the use declaration was simply
removed). That shouldn't have made it out, sorry.
For awhile now I've been cleaning up messages like 'info "foo"' to be 'info
("foo")' instead, since the former notation requires subroutine prototypes to
be used, which isn't compatible with the logging subroutines' placement in
ksb::Debug.
I've tried to just bunch up all the remainder into this single commit so I can
stop worrying about it.
This converts many of the plain die variants to what has turned into a more
standardized exception mechanism for kdesrc-build.
Not included are the svn/git update handlers since I want to do a bit more
verification of the implications, or die when used in a directly enclosing
eval{}.
kdesrc-build added code a few commits ago to use LWP's mirror feature
for servers that support If-Modified-Since, but the main use-case
(kde_projects.xml) suffered a misfeature in the generator causing the
XML file to change approx. every five minutes anyways, which meant the
download always happened.
The server now writes the XML in a canonical order which means
If-Modified-Since is useful and works... and revealed that LWP's mirror
feature doesn't set the "is_success" flag (which really just means any
HTTP 2xx code). So check for 304 specifically and keep rolling...
Aurélien Gâteau has informed me that libdbusmenu-qt has shifted
development awhile ago to be hosted on Canonical's Launchpad, which uses
the bzr SCM. He also informed me that the gitorious.org repository which
kdesrc-build had been recommending is no longer maintained, and very
politely requested help with having kdesrc-build support bzr.
On the one hand I really don't think it's necessary at this point to
allow for building bleeding-edge libdbusmenu-qt (I would be surprised if
kdelibs depended on a libdbusmenu-qt that hasn't been packaged for
months).
But on the other hand if it does become necessary we will be ready, and
this fits in well with the idea of building Qt and all of the
"kdesupport"-style libs in between Qt and kdelibs.
Unfortunately this shows I still have further to go in my
refactoring/documentation efforts since I still had to end up
implementing the support. But, it was certainly a much easier job than
it would have been before I had started fixing the codebase. This patch
was coded over no more than probably an hour or so (if that time were
consecutive... ;) and Aurélien tested overnight and after fixing my one
mistake reported that it worked swimmingly.
After installing bzr today I can report this works for myself as well,
and without having to insert "hacks" throughout the code to make it
work.
CCMAIL:aurelien.gateau@canonical.com
LWP supports a "mirror" function that forgoes downloading a file it's
already present and unchanged on the server (checked using
If-Modified-Since).
The features kdesrc-build uses LWP to download files for are all either
improved by using mirror or indifferent to it, so switch to avoid having
KDE infrastructure always have to send the same bits over the wire.
Now that we have build system metadata handling available we don't need
to retain that rc-file recommended hack to get strigi to build properly.
There's probably others I could remove as well.
Specifically, on first run in --pretend mode, where kdesrc-build has no
existing metadata of any sort downloaded, and no way to make a source
dir to hold incoming metadata.
Instead we just save it in a temp file.
The kde-build-metadata module still doesn't get downloaded though, and
so if you (for whatever reason) run kdesrc-build --pretend as your first
action upon installing kdesrc-build, you would not get 100% accurate
build plans.
Instead of special-casing that I think I would just add a --init or
--setup command line option and then tell the user to use that for
"--pretend in first-use" scenarios.
BUG:295715
This will allow for dumping HTTP output straight into the XML reader for
situations where no source directory is available (or in the worst case,
just using a temp file).
While testing an upcoming feature I noticed that persistent_data can be
stored as 'undef' instead of as '{}' which causes that store to be
forever unusable afterwards.
Now we verify that the persistent data is a hash ref when read in.
Michael Pyne
Burkhard Lück
Valery Yundin
Script Kiddy