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.
The return result obtained from the waitpid($monitorPid) will account
for a failure of the update process and force $result to be 1 (an error
status).
If the update was successful then $result is unchanged, which means if
the build process had failed, then $result would still indicate failure.
That didn't work due to the addition of the 'my', which masked the
top-level $result.
BUG: 330388
Attica for Qt4 requires being built with -DQT4_BUILD=TRUE on the cmake
command line, otherwise it will use Qt5 if it can find it.
Thanks to Riccardo Bellini for the report.
BUG:329797
FIXED-IN:1.16
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
Àlex Fiestas
Michael Pyne
l10n daemon script
Alex Merry
Ivan Čukić
David Faure
Alex Merry
Eike Hein
Kevin Funk
Martin Gräßlin
Sebastian Kügler
Gregor Mi
David E. Narvaez
Friedrich W. H. Kossebau