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
I am now aware of no major build system that couldn't be supported by
kdesrc-build...
The excuse in this case is the same as for last commit, namely to allow
for libraptor-2 support (their build system has CMake support, but it's
incomplete).
This is necessary in situations where the source includes more than one
build system (especially when only one of those actually works but
kdesrc-build auto-detects the other). The current example would be
libraptor.
This adds an option git-desired-protocol to allow for using HTTP instead
of git protocol when updating git modules.
For non kde-projects modules, it should already be possible to use an
http:// URL as a repository instead of git:// (though I haven't tested
this yet).
This should implement wish 305409.
BUG:305409
FIXED-IN:1.16
This audit was just comparing the list of config file options between
the documentation's list of options and the list contained in
kdesrc-build.
This resulted in adding an option (persistent-data-file) to kdesrc-build
to indicate that it's expected, and documenting an option
(use-clean-install) that was present but undocumented.
Right now this will be utilized for anything needing libwww-perl
(kde_projects.xml download, tarball snapshots), and will be propagated
to subprocesses via http_proxy environment variable, unless that
variable is already set.
Tested by using a simple HTTP proxy utilizing HTTP::Proxy from CPAN.
Implements wish 305411.
BUG:305411
FIXED-IN:1.16
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
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
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.
This commit should make the 'prefix' option expand this variable to the
module's name, so one can easily install each module into a different
directory.
Reviewed-by: mpyne
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
The option can actually still be passed since kdesrc-build accepts
command-line options matching known global option names, but since
we default to removing old log directories there's no reason to add 40
different ways to enable this.
kdesrc-build has supported emailing error messages for some time, at the
conclusion of the build process. There is no easier way to "modularize"
this code than to elide it completely, and given that no one seemed to
use it in the brief poll I conducted, I've removed it.
Awhile ago I started a subversion work branch so that I could
continue to update the Docbook docs for kdesrc-build. Now that
kdesrc-build is out of the SC (and the freeze is up anyways) I
can merge the changes/fixes back in.
Michael Pyne
T.C. Hollingsworth
Yuri Chornoivan
Burkhard Lück
Valery Yundin
Raphael Kubo da Costa