It is not necessary to name module-sets, that's just a convenience, so
remove names from single-module module-sets.
Also while kdesrc-build won't complain if the set's name matches a
module name (or path), that's not really a good idea, so try to make
remaining module-set names distinct.
Note this is a possible behavior change, if you got used to
"kdesrc-build kdepim" building a bunch of other things in addition to
kde/kdepim. My apologies but many users just want to build kdepim the
single repo, you can always copy the old file into a customized
kdesrc-buildrc.
kdesrc-build will process dependencies for kde-projects modules no
matter how they are referenced, as long as they are part of a module-set
using the 'magic' kde-projects repository.
Also the referenced kf5-extragear-build-include file only seems to pull
in a few modules, certainly not much of extragear and playground.
This option can be used to setup the user.name and user.email git-config
options within each new git repository cloned or installed from
snapshot, including kde-projects repositories. This can be useful for
KDE developers with multiple Git identities that they use for
development.
Module settings override global settings so you could e.g. have a global
git-user option for KDE modules and then override specific modules or
module-sets with a different git-user setting.
This setting is only applied during the initial git-clone process
though... if there's interest in having kdesrc-build re-apply settings
later that's possible too.
BUG:352478
FIXED-IN:15.09
The chomp doesn't return the chomp'ed value (rather '1' to reflect
number of characters removed), and fixing that revealed another bug with
my recent change to this code where I forgot to `tee' debug output to
the tty.
Should be a bit faster, but major goal here was to decouple the progress
output from the details of what we're outputting to. Functionality is
still the same (except that ninja progress output now works too) but now
it's that much easier to permit additional means of progress updates in
the future (e.g. a GUI, web server, even a Plasmoid).
When the initrepo script fails the extracted snapshot directory (the
srcdir) is deleted, but it's also the current working directory, which
breaks git when doing the fallback clone. Fix by switching to an
existing directory.
CCMAIL:faure@kde.org
Perl core includes a "HTTP::Tiny" module that does what little we need,
and has had it since 5.14 or so, so prefer that instead and remove the
requirement to install libwww-perl.
This also required removing the one minor instance of the URI module,
which is not technically in Perl core but was installed due to LWP.
Instead we just use a regexp 'blessed' by the URI module author.
There are currently various different paths to creating a Module (the
internal representation of a module from the rc-file). Depending on how
the Module is created you might get different options set for the Module
since the options are only available near the beginning (and are spread
across many different variables).
Consolidate some of this; this also has the side benefit of making
ksb::Application less of a dumping ground, and let's us get rid of a
'module-option-fixing callback' that needed to be used with a separate
'module-creating-by-name' callback.
Additionally this means that modules take only the options of the
module-set they were actually declared in, instead of the module-set in
use when the module was found (which may be different when using
--include-dependencies).
BUG:345192
FIXED-IN:15.05
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.
I noticed that I was getting error messages from a git usage after
install on my KF5 modules, which are configured to use
remove-after-install.
Turns out that git or the shell or kernel or something doesn't like
running a command from a now-invalid cwd.
The recent(-ish) switch to allow short name from a few months ago in the
dependency-data files was buggy in the way it handles "catch all"
dependencies.
Dependency information was already shortened down to just the module
name when it was compared against the wildcard dependency rules, which
made it impossible for most of the rules to match (e.g. a dependency for
kde/kdemultimedia/* wouldn't match against 'juk' anymore because at that
portion of the code it's not clear that juk is actually a part of that
set).
I will still have to make some other fixes to permit wildcarded
dependencies to work through indirect modules. E.g. a dependency exists
for kde/foo/bar/bar* to "first-module". A second module depends on
"bar-intermedia-module", which is really under kde/foo/bar/. If
"bar-intermedia-module" is actually being built this is not an issue as
the dependency resolver can read the full path to detect the recursive
dependency onto "first-module". But if "bar-intermedia-module" is not
being built then there's no way to tell that there's really a dependency
on "first-module" since the wildcard dependency would not match.
Instead of requiring wildcards to immediately follow a '/' character in
branch-group handling (or to be a bare '*'), allow for wildcards
following other characters since it seems CI supports that syntax. This
should fix branch selection for the KDE Telepathy modules.
Michael Pyne
Jeremy Whiting
David Faure
Martin Klapetek
Andreas Cord-Landwehr
Milian Wolff
Montel Laurent
David Rosca