I thought KF5 had removed /apps/ from the DATA_INSTALL_DIR, and so
adjusted the CMakeLists.txt install to match when it turned out my
module search paths were wrong. Turns out /apps/ is used, so put that
path and adjust module search paths instead.
Can't locate ksb/Debug.pm in @INC (you may need to install the ksb::Debug module) (@INC contains: /home/dfaure/d/kde/inst/kde_frameworks/bin/modules /home/dfaure/d/kde/inst/kde_frameworks/bin/../share/apps/kdesrc-build/modules....)
The "/apps/" was missing in the actual install path.
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.
Should be a bit faster, but major goal here was to decouple the progress
output from the details of what we're outputting to. Functionality is
still the same (except that ninja progress output now works too) but now
it's that much easier to permit additional means of progress updates in
the future (e.g. a GUI, web server, even a Plasmoid).
There are currently various different paths to creating a Module (the
internal representation of a module from the rc-file). Depending on how
the Module is created you might get different options set for the Module
since the options are only available near the beginning (and are spread
across many different variables).
Consolidate some of this; this also has the side benefit of making
ksb::Application less of a dumping ground, and let's us get rid of a
'module-option-fixing callback' that needed to be used with a separate
'module-creating-by-name' callback.
Additionally this means that modules take only the options of the
module-set they were actually declared in, instead of the module-set in
use when the module was found (which may be different when using
--include-dependencies).
BUG:345192
FIXED-IN:15.05
This is to support being able to improve and expand the test suite by
(eventually) having a simple function call to setup different modules to
be tested.
This is a long-overdue change that allows for overloading the
stringification operator to produce better error messages.
BuildException was previously not an actual module since kdesrc-build
itself was just a single script file. Now that we allow modules on disk
there is no reason to leave the exception class as a figment of Perl's
imagination.
We need a better name for this feature.
But basically, this allows for creating kde-project repository-wide
"branch groups". For instance, you could list the git branch to use for
the "stable Qt/KDE 4" release/maintenance branch, the "new development
Qt/KDE 4" development branch (typically master, but that has been
changing), and the "upcoming next major release" branch (for us, this
means 'frameworks' sometimes, means 'master' sometimes, other modules
may have different ideas).
By using the 'branch-group' option (which remains to be further
documented) you can say that you want to defer to the metadata about the
repository branches stored in
kde-build-metadata/logical-module-structure. kdesrc-build should even
track branches for you as they are updated by the Release Team, if you
simply want to hang out on stable but compile your own stuff.
Note that this support requires Perl's JSON module (which should come
with Perl 5.14 if I understand it right, but you probably want to
install JSON::XS from CPAN). JSON support is only required for this
feature, it is not a new overall dependency.
See also: http://community.kde.org/Infrastructure/Project_Metadata
It's a bit of a chicken and egg problem, otherwise. Well, of course one
can use kdesrc-build uninstalled, but this way an automated build host
can just start with "./kdesrc-build/kdesrc-build kdesrc-build" to ensure
it's up-to-date :-)
use the SUBDIR parameters for kde4_create_handbook, so it installs in the proper place
remove the comment related to the issue, and enable the doc subdir
To avoid kdesrc-build build errors, it's probably easiest just to
have a shell CMakeLists.txt which CMake can process and do nothing
with.
At some point it will be used to make the docs build, but right
now the docs install to the wrong directory (as if the name of
the project was "doc" instead of kdesrc-build), so installation
is disabled.
Michael Pyne
David Faure
Ben Cooksley
Stas Verberkt
Pino Toscano