This installs needed KDE-related environment settings without going so
far as to install .xsession support. For that, see
install-session-driver, whose documentation has been fixed to make clear
it's not a default.
This makes it more convenient to work with baseline configurations (that
are 'include'd) without changing the upstream configuration.
Still to do: add a warning when modules and module-sets end up sharing
the same name somehow.
BUG:365813
FIXED-IN:16.08
adapt header to doctools.git / src / templates
fix wrong + outdated links
use new repo address scheme
set date to 16.05
use http://code.qt.io/cgit/qt/ for Qt repo
add some fixme's where the docbook seems to be wrong or outdated
REVIEW:127820
This still takes too long for most shell shortcuts, but will make it
possible to do things like setup shell functions to cd right to a build
dir based only on a module name, check for which git branch a module is
resolved to, or see what config file options a module ended up falling
under.
As part of the documentation changes, I also ported the docs to KF5.
The docs have been at docs.kde.org for a long time, now they're the one
and only recommended location. But I forgot to update the URLs
referenced by the script itself. :(
BUG:357162
FIXED-IN:16.01
This option can be used to setup the user.name and user.email git-config
options within each new git repository cloned or installed from
snapshot, including kde-projects repositories. This can be useful for
KDE developers with multiple Git identities that they use for
development.
Module settings override global settings so you could e.g. have a global
git-user option for KDE modules and then override specific modules or
module-sets with a different git-user setting.
This setting is only applied during the initial git-clone process
though... if there's interest in having kdesrc-build re-apply settings
later that's possible too.
BUG:352478
FIXED-IN:15.09
Add and document the --include-dependencies option. Useful with
--print-modules as a quick way to determine what dependencies a given
module on the command line has, especially if you do a quick
"kdesrc-build --metadata-only" first.
Also, make selecting modules on the command line override
"include-dependencies" as an rc file option, since otherwise it's
impossible to ask just to build a single module if that module is in a
module set with included dependencies.
Use the newly-added --include-dependencies option to force dependency
resolution to happen even if you specify modules to build on the command
line.
Currently it (probably) doesn't support pulling in options for these
modules from their host module-sets (although using 'options' sections
might actually work). I think it ignores the 'ignore-modules' option as
well.
Other than that, it should do pretty much what it says on the tin,
although I had to implement a few other bug fixes as well to get it to
that point.
I want to say that there was an open bug for this but I can't seem to
find it now.
This commit makes the kde-build-metadata module a requirement instead of
an option, since the vast majority of runs will require this module now.
Additionally the --metadata-only option is added and documented to allow
for downloading the kde-build-metadata module alone (and make the
--pretend option work afterwards), and kdesrc-build recommends using it
if you run with --pretend and without metadata.
This should hopefully make the first-run use case easier for users.
BUG:337446
FIXED-IN:1.16
I had made some build-system related options not automatically apply to
modules with customized build systems (e.g. Qt, CMake, "custom"). But
this seems like the kind of option we'd want to have in common, as noted
in a bug report to me by Andre Wöbbeking, so make make-install-prefix
apply to all build systems by default if it's a global option.
This can, of course, still be overridden for individual modules or
module-sets.
This is a first-step hack to have non-default build systems ignore
global options which are related to the build system in use (e.g.
compile or make flags, install/uninstall options, etc.).
This should fix bug 331654 (now that I understand it better) and improve
the situation for bug 332789 (which would be the long-term fix when
implemented).
BUG:331654
CCBUG:332789
FIXED-IN:1.16
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
Michael Pyne
l10n daemon script
Burkhard Lück
Yuri Chornoivan
Àlex Fiestas