Now you don't have to do --stop-on-failure=1.
--resume is documented in the man page and docbook, but basically lets
you resume the last build list quickly without source or metadata
updates, starting from the module that failed. If you want to skip the
failed module, look into --resume-after and --stop-before.
BUG:331941
FIXED-IN:1.16
This patch does three things:
1-Adds --install-only for the sake of consistency
2-Adds --install into the usage
3-Makes the CMake (KDE4) build system use make install/fast.
make install/fast only performs the installation of the files
thus avoiding a double compilation.
REVIEW: 116589
Does about what it sounds like, but quicker. Useful for checking to see
what kdesrc-build is resolving module dependencies to. The beginning
output is intermixed but you can grep for "* Module list" if you want
and everything after will be module names.
Add a specific config file grouping (which acts just like a module
declaration), to allow for specifying options to override a
previously-declared module.
The use case here is for a module-set: You can specify options which
apply to an entire module-set when declaring the module-set, and then
override those options with any changes in a later "options"
declaration.
These declarations can stack too, so this can also be useful for
multi-level file includes (but this is less useful since an "options"
declaration requires a specific module, it doesn't work on module-sets;
in that case you'd want to have the different module-sets in your
most-specific included config files instead of in a base file).
Tested on my personal test case for bug 321883, and on a --pretend run,
and with a bug 321883 test case modified to not pre-declare the
overridden module first.
Example:
module-set kde-mm
repository kde-projects
use-modules kde/kdemultimedia
end module-set
options kmix # Not mentioned before this line
branch KDE/4.11
end options
In this case kmix would use KDE/4.11 branch while juk (and the rest of
kde-mm) would use whatever the global branch or branch-group was
(probably 'master').
BUG:321667
Adds ignore-kde-structure option which will fetch and compile all
projects in the same dir, meaning that instead of:
extragear/network/kde-telepathy/ktp-text-ui
it would be just
ktp-text-ui
Kind of a mouthful, but remove a filter that was added to avoid
automatically including an actual git repository's children that were
also git repositories. E.g. think of something like a SuperBuild git
module that also had its component git modules as logical children
within projects.kde.org.
This filter is unnecessary now that kdesrc-build supports both kde.org
metadata (kde-build-metadata/build-script-ignore) and user-configurable
module filtering (ignore-modules option).
More importantly this filter precludes many other desirable types of
group syntax (e.g. including all of kdebindings just by asking for
kdebindings).
So we remove the filter. The trouble I've seen so far is that it is
now rather difficult to build *only* kdelibs, since kde/kdelibs is a
logical parent of nepomuk-core, nepomuk-widgets, and kactivities. This
can be worked-around by using a normal single module declaration. E.g.
module kdelibs
repository kde:kdelibs
end module
On the other hand, the recently-added config file option
"ignore-modules" should now remove any kde-projects modules that contain
a path component(s) matching the ignored module. You may have to be
specific with a given ignore atom for this reason (e.g. ignore
playground/libs, not 'libs' otherwise you'll also ignore
kdegraphics/libs at this point... though that was also true before this
commit).
BUG:321667
Should hopefully be pretty much what it says on the tin. Stop either
right before or right after the given module. (GUI flag since this
involves documentation changes to the Handbook and man page).
BUG:315251
FIXED-IN:1.16
GUI:
It's kind of annoying to be unable to build all modules in a certain
kde-projects module grouping, *except* for some certain chosen ones.
Now you can: You can add the ignore-modules option in your module-sets
using kde-projects repository.
It accepts a space-separated list of module names (either kdefoo or
kde/module/kdefoo style) to ignore.
Although the intention is to only filter out matching modules in *that*
module-set, it would actually perform the filtering even if you
accidentally put it in the wrong module set due to a fluke of the
implementation (I recommend not relying on this, however).
The documentation has also been updated, including an example of the
usage.
This implements the command line option mentioned in the last commit, to
allow for overwriting .xsession (and possibly .kde-env-master.sh, if it
exists).
Probably would still be a good idea to make a backup though.
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
Michael Pyne
Yuri Chornoivan
Àlex Fiestas
Burkhard Lück
Luigi Toscano
T.C. Hollingsworth