The Coverity plugin interface was removed awhile ago and I've seen no
anguished screams since. I can only assume Coverity no longer uses
kdesrc-build for KDE code scanning (I am uncertain whether Coverity
still checks our code base at all).
I was also half-tempted to just force-exec the setup script if it's
available and there's no config, but there are some scenarios where it
might make sense to just download kdesrc-build and kick off a very quick
build from there (especially with the +xml-module syntax on the command
line).
Ask requested by dfaure, belatedly add a --no-tests option to disable
enabling tests *at CMake* time for that run. Delayed since I was going
to implement it after refactoring out each step into independent phases
but I haven't quite made it that far yet.
BUG:265275
FIXED-IN:1.14
The option can actually still be passed since kdesrc-build accepts
command-line options matching known global option names, but since
we default to removing old log directories there's no reason to add 40
different ways to enable this.
kdesrc-build uses multiple processes for its operation (even without
async mode), the way Perl works means its END {} handlers get called
even for the children.
The real way you'd normally see this is by doing ^C at the terminal, the
signal handler would manually run the exit routines and then the END {}
block would run the same routines.
If a user generates a configuration file that kdesrc-build won't pick up
by default, then show a message after the setup script runs warning them
about that and letting them know what they have to do.
Now it supports:
* Backup existing configuration and overwrite
* Custom configuration filename.
* It even automatically falls back to a tempfile if backup fails.
Ever since kde-projects XML support was added you could (in theory) use
the syntax +modulename on the command line to force kdesrc-build to
interpret that module as an XML module.
Later a filter was added to avoid building modules on typos, which also
trapped all +modules.
Now if you use +module on the command line kdesrc-build will keep
processing it, and catch misspellings later or build the whole module if
it's actually defined in kde_projects.xml.
kdegraphics actually needs it as of this writing since it is marked as
inactive in projects.kde.org. Even if it is made active, kdegraphics's
repo should not be built in conjunction with its logical children's
repos.
As suggested by dfaure and at least one other person whose name escapes
me now, with all the modules available in git.kde.org it makes sense for
their on-disk layout to match the hierarchical organization given in
projects.kde.org, so kdesrc-build now does that.
If there's a big hub-bub about this I can make it optional, however I
think it should hopefully not be too hard to adjust to. A later commit
will add auto-migration of old source/build dirs because I love you all.
CCMAIL:dfaure@kde.org
Modules like kdegraphics are both the ancestor of a group of logical
child modules, and repos in their own right. kdegraphics is marked as
non-active since it's repo just exists to allow for building the
subprojects, but that means kdesrc-build won't build it.
So, allow for specifying modules *under* a given module. This allows for
a syntax as follows to work:
module-set kdegraphics-set
repository kde-projects
use-modules kdegraphics/libs kdegraphics/*
end module-set
(The kdegraphics/libs forces those modules to be added first. They will
not be readded by the later kdegraphics/*)
This doesn't allow for resuming at this point but if it's not too hard
to add and there's interest from the sysadmins I can look into that too.
Either way it should allow for a load reduction on git.kde.org (or
rather, anongit.kde.org), but this only works for modules accessed
through the projects.kde.org XML database (i.e. repository kde-projects
in your module-set)
Trying to build a module-in-migration gives a confusing error message in
master, and gives an even-more-confusing "successfully did nothing" type
of response in the modularize branch.
Look for empty XML module expansions and give a warning message if they
don't result in anything to avoid that.
The test suite now works again. One test related to the kde-languages
option was removed since I expect that the feature is not ready, but all
other tests still pass.
File::Path even includes the "pruning under a directory" feature that
dfaure had requested to be added so long ago. Would have been a lot
easier to implement that if I had known about File::Path! ;)
Raphael Kubo da Costa
Michael Pyne
David Faure