I was noticing that sometimes Ctrl-C at the TTY doing a kdesrc-build -p
left a monitor process hanging at 100% CPU, not to mention all the
kdesrc-build processes spamming goodbye messages.
It didn't help that I was doing waitpid on an updater PID when that
updater PID had to be 0 by definition.
Either way, I've verified that the forking going on here shouldn't start
a different process group for the shell session, so ^C is already going
to all of the relevant processes. We just need to make sure to catch the
signal and do the right thing (i.e. exit the child process).
What we really want is for this to actually allow many modules I
suppose, but for now you'll need to use the config file with module-sets
to get the same effect.
The last implementation didn't actually match the comments, which was
causing the optimization I committed yesterday to not find some modules
it should have.
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
It's possible for the build process to end far before the update
process, in which case kdesrc-build would wait for the updates to finish
due to waitpid().
Instead send along a SIGINT to cause the update and monitor procs to end
too.
I have a fairly large kdesrc-buildrc, and simply doing a
"kdesrc-build --pretend kcalc" (where kcalc is not directly mentioned in
the config file) was taking 32 seconds to complete, since kdesrc-build
would have to go through each possible kde-projects source of kcalc,
and XML-expand it, in order to find kcalc.
Before this fix, each XML-expansion read the whole XML file looking for
modules matching the search string. Then, everything about the XML file
was completely forgotten.
Now the XML file is read only one time, and every possible kde-projects
module is remembered. We then filter the list of modules each time
there's a request. We can probably optimize this still further, but this
alone is enough to get me down to 3-4 seconds locally.
My KF5 installation doesn't show anywhere near as much improvement (but
then it didn't have anywhere near as many different use-modules entries)
so YMMV.
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
Michael Pyne
David Faure
Martin Klapetek
Alex Merry
Yuri Chornoivan
Teo Mrnjavac
Àlex Fiestas
l10n daemon script
Ivan Čukić
Alex Merry
Eike Hein
Kevin Funk