Qt5 modules built from git rely on git information being available to
generate private headers and the like, so don't strip out the .git
directly when using builddir hack.
Likewise, using the "-r" flag to force a full recursive search for .pro
files causes qmake to error out on some modules where the .pro isn't
meant to be built as part of the module build (e.g. examples).
I thought KF5 had removed /apps/ from the DATA_INSTALL_DIR, and so
adjusted the CMakeLists.txt install to match when it turned out my
module search paths were wrong. Turns out /apps/ is used, so put that
path and adjust module search paths instead.
This allows for many useful language improvements, especially support
for new package declaration syntax and the use of array/hash operators
on references. 5.14 has been out for a few years now, and AFAIK is now
available in all recent distros.
This makes kdesrc-build fail to clean the build directories if there are
files without write permissions -- this happens if a CMake version with
automoc support is used, as AutomocInfo.cmake (aka AutogenInfo.cmake) is
written with the permissions of CMake's Auto{gen,moc}Info.cmake.in,
which can be 0444 in some systems.
REVIEW: 119263
By moving this code and associated utility methods into Application we
nearly complete the long-in-progress refactoring of the monolithic
kdesrc-build script into proper classes/objects.
The kdesrc-build script itself is nearly bare, but there's still a bit
more to do.
At least it should be easier to make individual test scripts to test
different bugs instead of having a monstrosity of a kdesrc-build-test
script that has to maintain a common state.
I've tested this in each way that I'm able (run needing to make a new
source dir, build dir, new install and log dir, run updating existing
checkouts, bzr/svn/git/kde-projects all tested, etc.). But this was a
large move so let me know if I've missed anything.
This is to support being able to improve and expand the test suite by
(eventually) having a simple function call to setup different modules to
be tested.
This is a long-overdue change that allows for overloading the
stringification operator to produce better error messages.
BuildException was previously not an actual module since kdesrc-build
itself was just a single script file. Now that we allow modules on disk
there is no reason to leave the exception class as a figment of Perl's
imagination.
Another regression from the introduction of ksb::ModuleSet, modules
passed on the command line that are matched within the rc-file don't
cause the metadata module to be required since the check happens too
early.
This is unfortunately a giant change, as all of the functionality that
is encompassed into module-sets currently had to migrate over to
multiple separate classes, including the new ksb::ModuleSet class and
subclasses.
This was a long-overdue change, however, and should allow for accurately
tracking a source module-set for a given module.
On the other hand this migration of logic has made it easier to
understand each of the individual pieces where they stand (e.g. there is
no longer a separate expandXMLModules and expandModuleSets).
In addition we can properly handle ignore-modules with wildcards just as
we do with use-modules (they even use the same matching logic) which
means that it is safe to integrate this into master (assuming no extra
boogs get added, of course).
This will also help with fixing some of the extant module-selection bugs
(321883, 299415).
BUG:321275
CCBUG:321667
This fixes this warning:
* Module zanshin is apparently XML-based, but contains no
active modules to build!
when doing this:
module-set
repository kde-projects
use-modules zanshin
tag 0.2.1
end module
In the past some KDE SVN modules used the "svn external" feature to pull
in other SVN repositories. These svn-external links were on the *server*
side so the link URL had to use a single scheme.
This scheme was https, which caused quite some problems for anonsvn
users just trying to update from SVN being an unattended kdesrc-build
run, as the SSL cert for svn.kde.org was not signed by a well-known CA.
As a result kdesrc-build updated svn automatically with the expected KDE
SVN SSL signature to avoid blocking on the interactive warning.
This is no longer required. The modules that used svn externals have
pretty much moved onto git now. The new svn server does not even have an
https interface, so this is dead code now, and removed accordingly.
Once I figure out a "preferred" solution for this use case I'll probably
convert to that, until then no reason to pollute with warnings.
I've run a search for other uses of given/when and didn't see any.
Should be permanently fixed this time by doing what I should have done
in the first place and making the "needs metadata?" predicate a separate
return value.
Should hopefully be pretty much what it says on the tin. Stop either
right before or right after the given module. (GUI flag since this
involves documentation changes to the Handbook and man page).
BUG:315251
FIXED-IN:1.16
GUI:
applyModuleFilters() would quite happily filter out the metadata module
automatically added to a kde-projects build.
Without the metadata module, later code paths wouldn't know that they
should perform dependency resolution or handle build-script-ignore (as
all 'proj' modules have been expanded to 'git' modules by that point).
BUG:315394
FIXED-IN:1.16
Really I should probably factor out the various 'proj'-creating routines
into a single point of awesome but for now let's just use the old
behavior as a backup in case users give command-line modules...
Commit aa1e4b9542 introduced changes to
how "proj" modules are first parsed (simply keeping the last path
component as entered by the user as the module name).
The unintended side-effect of this is that the user doesn't always have
to enter path ending in an actual repo. E.g. extragear/utils is not a
repo, it would get reduced to "utils", and later KDEXMLReader would
effectively look for all repos matching "*/utils/*".
For more fun, do what I did and try "kdegraphics/libs" => "libs" =>
"*/libs/*"...
Anyways, the fix here is to use the normalized module name as the module
name, but use the full user input for the XML search.
CCBUG:299415
The build thread owns the TTY in the current setup. To keep the update
and build processess from fighting over the TTY when in async mode,
we've been simply squelching the update output up to this point, except
for errors.
This is not really the best idea as it can leave out kind of important
details. With this change we configure the logging subsystem to forward
its messages that it would ordinarily print out to instead go over an
IPC channel.
The IPC channel knows which module is currently being operated on, tags
the message, and forwards it over to destination proc's IPC handler,
which extracts it and holds onto the message until that proc reaches the
same module.
Once the receiver proc is processing the module, those messages are all
output at once and then normal processing resumes.
In case some messages are never read out this way (e.g. a module is
updated but never built) we have a message scavenger right after the
build is done to give those messages as well.
It's kind of annoying to be unable to build all modules in a certain
kde-projects module grouping, *except* for some certain chosen ones.
Now you can: You can add the ignore-modules option in your module-sets
using kde-projects repository.
It accepts a space-separated list of module names (either kdefoo or
kde/module/kdefoo style) to ignore.
Although the intention is to only filter out matching modules in *that*
module-set, it would actually perform the filtering even if you
accidentally put it in the wrong module set due to a fluke of the
implementation (I recommend not relying on this, however).
The documentation has also been updated, including an example of the
usage.
For whatever dumb reason I coded the "ignored kde-projects modules"
handling (kde-build-metadata/build-script-ignore) by having the code
that reads in the list of ignored modules go and immediately update the
build context.
For obvious reasons this only works when the update is actually
performed, which means ignore information wasn't used in pretend mode.
We fix this by moving the build context update to the rest of the
metadata handling.
Michael Pyne
Raphael Kubo da Costa
David Faure