Laurent Montel reported an error that indicates a syntax error in the
git error handler for the kde: support. Even after extracting out the
error handler and forcing it to run Perl works just fine here, so it's
not a semantic issue either.
So instead, just use a plain 'ol Perl 5.0-style hash to figure out the
error message, no need to make it complicated.
In addition I added the stderr > /dev/null redirection that I forgot to
have in place before.
asciidoc was a nice start, but modifying the generated XML is not too
bad (and must be done to comply with KDE documentation guidelines
anyways).
So, remove the asciidoc and instead generate man pages from DocBook XML.
I've taken the liberty of using the more specific content tags but the
overall content should be approximately the same.
I probably should have done this a long time ago, but now kdesrc-build
has a man page (mostly to get rid of the 1 Debian lintian hit I saw for
1.13)
I haven't tied it into CMake yet because I'm tired, but it requires
asciidoc and the short story is:
$ asciidoc -d manpage -b docbook kdesrc-build.1.txt
$ xsltproc --nonet /usr/share/asciidoc/docbook-xsl/manpage.xsl
kdesrc-build.1.xml
Of course finding that damn XSL from CMake will be the problem in the
future but I can figure that out tomorrow if no other kind soul does
that for me.
Raphael Kubo da Costa noticed that his set-env in module-sets were no
longer working in master.
Turns out a simplification of the setOption method to allow accepting
more than one option did not properly handle the set-env option if that
option had already been processed. (kdesrc-build has to convert set-env
read from the rc file into a hash instead of just storing the value to
allow for duplicate set-env entries).
This is fixed by ensuring that if that processing step has apparently
already been completed, we don't try doing it again.
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
Michael Pyne
David Faure
Yuri Chornoivan
Raphael Kubo da Costa