This makes it safe for things like extragear software to simply
generically depend on kf5umbrella and have kdesrc-build do the right
thing.
Fixes bug 331940, though I know dfaure mentioned it at some point as
well.
FIXED-IN:1.16
BUG:331940
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
I'd normally just go "Ship it!" but I changed this file earlier today to
use module-sets, and this is pretty literally the easiest change in the
world now.
REVIEW:116571
This should be absolutely transparent except that "kde-kactivities" will
rename to "kactivities", though you might have to update
kde-build-metadata first if you're using --pretend to test changes.
With --verbose kdesrc-build will add a description of what dependencies
it thought each module had to the build output for that module.
With --debug the "Visiting module foo" entries will be arranged
hierarchically in accordance with the tree dependency structure.
Otherwise you get an interesting interaction with --refresh-build and
remove-after-install options: remove-after-install removes the previous
build directory, and --refresh-build tries to prune under the new
build directory, which fails since the Perl module that does this first
tries to detect the cwd and fails (since we removed it).
KRunner depends on Plasma-framework, but (because kdesrc-build
apparently assumes config file order is more reliable than dependency
info in kde-build-metadata) it gets built first, which is an issue when
you are doing a completely clean build.
This includes moving plasma-framework to kf5-frameworks-build-include
where it belongs.
REVIEW: 115893
We'll want to look into how we want to handle more applications becoming
available for Frameworks 5/Plasma Next... somehow I doubt every KF5
hacker will want to build every application as we start getting more
ready. :)
REVIEW:115632
We use a mix of error codes and raw exceptions in the git updater.
Fix this to use the exception objects used elsewhere (and which give
better error messages).
This also simplifies the code by removing error code returns from some
internal functions whose return value is then just converted into an
exception anyways. Easier just to throw the exception directly and
simplify the higher-level functions.
The one nuance here is that installing a git snapshot can fail yet that
should not cause an exception, we'd just fallback to doing a normal
git-clone.
I don't think anyone ever uses it, but I tried just now and I'd broke
it, as the type of the variable holding the return value was wrong.
If "modulefoo" is completely unknown in the rc-file then it will handle
it as a module-set as well, so that you can quickly build something like
'frameworks' if you'd wanted to.
Sayonara, time-tracking. If you need to know elapsed time, run "time
kdesrc-build" (or just look at the mtimes and atimes of the files in the
log directory).
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.
I was so convinced this was already the case that I told dfaure that was
how the code worked and so it would be hard to find the bug he was
experienced. Whoops.
The corrected code now employs dependency resolution before the
second-pass --resume/--start handling, so that kdesrc-build should still
build modules after their dependencies are built.
This did give me the opportunity to clean up the metadataModule TODO
finally. Now there really is only one place that tracks whether we use
metadata or not, just like it should be.
The recent port to Getopt::Long broke the ability to use --foo=bar type
of options (where <foo> is a global option name known to the build
context). It also replaced the --module,foo=bar options with
--set-module-option-value=module,foo,bar.
While it's possible to use the latter syntax for global options (by
using 'global' as the module name) that is undocumented and may not work
forever. And either way, --foo options did use to work, and I noted it
was broken in the refactor.
So now that someone else has noticed I've reimplemented the feature.
It's difficult to do entirely from within Getopt::Long since the
documentation for that module gives you essentially one catch-all, which
only supports *non-options*.
So what I've done instead is to have kdesrc-build dynamically introspect
its list of global options and flags and then add them to the list of
valid options we pass to Getopt::Long. This also should mean that we
don't need to pass 'pass_through' as an option to Getopt::Long anymore,
though we'll see.
This code path won't be used for options that already have a command
line option (such as --async/--no-async) so that is still a misfeature
compared to how it was before, but I guess it can't be perfect. =D
I've tried to ensure that "flags" support the 'false' value to mean
boolean false, but be careful to pass false or 0 if that's what you
mean... specifying --dont-foo without giving it a value defaults it to
true.
BUG:330386
This is just a rearchitecture, but separates the internal build context
options into:
* flags (true/false settings), can be altered from cmdline.
* varible options, can be altered from cmdline.
* internal options, cannot be altered directly from cmdline.
Michael Pyne
Teo Mrnjavac
Àlex Fiestas
l10n daemon script
Alex Merry
Ivan Čukić
David Faure
Alex Merry
Eike Hein
Kevin Funk
Martin Gräßlin
Sebastian Kügler
Gregor Mi