i.e. was the module list given on the command line directly, or allowed
to be generated from the config file. It's only coarse-grained (e.g.
filtering options on the command line still count as modules coming from
the config file).
This will be used for properly handling the order for module uninstalls
and possibly for restoring old behavior on module installation with
--install.
Now fix the manual install phase (i.e. when you specify --install on the
command line).
One behavior change is that kdesrc-build used to install only modules
that were successfully built if you ran only "kdesrc-build --install",
now it will try to install modules that it would normally try to update
and build, and since "make install" command normally implies a build
this can make the install process take a bit longer since you're still
doing a build anyways.
If this is actually an issue to anybody just let me know and I'll adjust
to get closer to the old behavior.
get_build_list used to be used to not only "get the build list", but
also filter out modules to build based on --resume-from and
--resume-after. kdesrc-build now generates a list of Module objects
which was not tied into get_build_list, but now the old behavior is
back (and improved, --resume-foo doesn't force --no-src anymore).
As noticed by dfaure. It turns out that I was simply lazy and didn't
want to use the same logic in both get_update_list and get_build_list,
but those functions are effectively useless now anyways with the new way
of figuring out modules to work on (although there's still a few
bugfixes needed for that new code).
It used to be that unknown modules would simply be attempted to build
anyways, and it would be amusing if it failed, but with the new method
of handling regular and XML-based modules, an unknown module simply
causes no output and a successful return message.
Now it results in an exception being thrown.
Basically, nothing good can come of more auto-guessing of this style.
dfaure has encountered issues with it, and I've run into a few yourself.
Just specify the right repository (and you should be using module-sets
by now anyways) and we'll all be OK. ;)
Having use-modules and use-xml-modules is stupid.
Instead, you can use "kde-projects" for the existing repository option
to allow kdesrc-build to know that you mean for the module to be built
based on the KDE Projects structure, and kdesrc-build will handle the
rest, and then use use-modules as normal.
This means that you can't mix XML-based modules and the old-style
modules in the same module-set, but oh well...
You can still use +-prefixed module identifiers on the command line as
well.
set-env requires using the internal handle_set_env to get setup
properly. Actually use it.
In addition, actually copy module-set options over to xml-based modules
as well.
By naming module-sets, it becomes possible (with some more work in this
commit) to quickly build given module-sets from the command line,
instead of having to still laboriously give labels to every module
contained within the set.
kdesrc-build tries to figure out if a module is git-based or svn-based
automagically. Now the script will see if the 'repository' or
'svn-server' settings are set directly for a module and if so, those
factors will take precedence.
Otherwise kdesrc-build will still prefer an existing .svn directory to
guess svn, but in the future kdesrc-build will start tending to guess
git if there's no other info.
With some git module IDs in the XML ending up the same as still-used
Subversion modules, it makes more sense to maintain the existing status
of present source directories instead of trying to use the wrong scm
tool.
Later I need to add detection for e.g. "MIGRATED" files to influence scm
type detection, but this works a bit better for now.
I ported to use a key instead of a value.
In addition, properly tell whether a class method (for package Module)
is operating as an object method or as a class method.
I get a lot of errors about things not being a git module, which leads
me to believe that auto-detecting whether a module is svn or git is no
longer working, so test with care.
Basically all I did was hook the new code right in front of the old code
so it's still a bit messy, but it seems to me that it should work fine
in theory (all options are still held where they used to be, and the
update_list and build_list variables are still available and have the
same type).
kdesrc-build now supports building XML modules from the command line
(well, building is disabled in favor of debugging printouts, but the
module list gets setup right at least).
To force a command-line module to be thought of as an XML module,
precede the name with a +.
e.g. kdesrc-build --pretend +kde
is instructive at this point... ;)
This updates the modules that kdesrc-build would build without so much
as an available config file. This really needs updating to move a
default configuration file to the build-support git repo and then having
kdesrc-build simply bootstrap from there. But this will do in the
interim.
This change refines module support a bit by introducing a Module object
for use by the rc-file and command line option-reading code. What's
needed next is to move the XML module expansion from parse_moduleset to
occur after process_arguments() and read_options() (but before the
actual rest of the process, of course).
kdesupport used to have tags made up of the form kdesupport-for-4.2,
kdesupport-for-4.3, etc. which contained the releases of the various
underlying different libraries that were minimum requirements for the
corresponding KDE version.
Now that kdesupport is mostly moved to git, those tags are not being
created, so don't bother trying to guess them for 4.6 and greater.
I broke the code that determines whether git-stash is determined in
commit 2b0d0d6248. The problem is that
the system() Perl function returns the exit code and miscellaneous
process exit data (such as whether the process failed to run, etc.)
and I actually needed that data.
In the commit I refer to, I switched to my safe_system() which only
returns the exit code and now kdesrc-build thought there was an error
running git, when instead git was returning the proper exit code for
a module with local changes. Thanks to dfaure for the report.
Not closing the bug here in case I merge this somewhere else later.
CCBUG:265325
This commit adds initial support for the projects.kde.org XML database
as exported by https://projects.kde.org/kde_projects.xml
The short story is, to use the "use-xml-modules" option in a
*module-set*. E.g., what I just tested was with
module-set
use-xml-modules phonon-gstreamer
end module-set
If you want --pretend to work you should throw a module set that uses
XML modules in somewhere and try having the XML-based module built, or
just download kde_projects.xml yourself and plop it right in the base
source directory.
In theory a grouping module (such as extragear/utils) should allow you
to recursively grab and build every module composed within it.
However, modules that contain a <repo> tag, and then have children
underneath also containing <repo> tags only have the very base <repo>
tag working (if I coded it right ;)
The reasoning for this is to allow module groups where you can build the
entire module, or given subsets of it (e.g. Calligra allows this from
what I can tell, you can build Calligra or assuming you've met the
dependencies, Krita).
If a module has no direct <repo> tag, but includes modules or projects
or whatever that each have their own <repo>, then everything should be
recursively built.
kdesrc-build obeys the <active> tag, so modules that claim not to be
active will not be built by kdesrc-build (at this point, even if
directly passed on the command line, although that may change later).
I'm super-tired and won't have time to test throughout much of this
week, so I've put it in a branch. Feel free to test yourself if you're
interested though!
I'd like to thank Allen Winter who contributed the core XML parsing
code, it was a big boost to getting something working. :)
kde-qt has become qt-kde, and moved from gitorious.org to git.kde.org.
This updates the locations in the kdesrc-buildrc-sample and the built-in
configuration.
I had left git-diff as system() instead of safe_system() (which
respects --pretend) when looking to see if git-stash needed to be run.
However, this can sometimes significantly slow down the kdesrc-build -p
run, and the only real benefit was not confusing users with git diff and
git diff --cached command lines.
Awhile ago I started a subversion work branch so that I could
continue to update the Docbook docs for kdesrc-build. Now that
kdesrc-build is out of the SC (and the freeze is up anyways) I
can merge the changes/fixes back in.
This just adds some simple logic to see if a Subversion-using module has
been migrated to git (by looking for a MIGRATION file as per the
kdepimlibs example).
Looking for README is possible to code, but many modules already have
one so I didn't go that route.
BUG:264685
Michael Pyne
David Faure
Yuri Chornoivan
Montel Laurent
Script Kiddy
Stas Verberkt
Pino Toscano