The way kdesrc-build handles letting users type "use-modules frameworks"
and getting everything in frameworks/* back is by implementing the
wildcard search in the KDE XML reader that parses kde_projects.xml. This
uses a two-pass search for simple names, looking for 'name/*' and
'name'.
This results in duplicates, which are normally OK due to other features
in kdesrc-build that prevent duplicate modules from making it into the
build list. However a feature I'm implementing was made much more
difficult by this; easier instead just to prevent finding dups in the
first place.
This is somewhat confusing; since modules are listed in build order,
indented modules show up *before* the modules that require them.
Essentially, the module that caused an indented module to show up in its
position in the build is the next module in the build that is more
outdented.
Additionally, this only indents in situations where a module's build
order had to be rearranged. Modules that were already in the right order
are not specially indented even if a valid dependency exists.
With all that said, this can be a useful way of determining why
kdesrc-build thinks a given order is required without having to go the
route of a complicated ASCII DAG renderer.
This feature had been intended for cases where a module kde/foo was a
git repository while also being a base for other git repositories
kde/foo/bar, kde/foo/baz, etc. For instance, kde/kdelibs is a git
repository that also held sub-children like kde/kdelibs/kactivities.
However this is fairly rare in KDE repositories now, and this feature in
its easiest-to-implement form has always had to navigate around several
corner cases, so it's better just to explicitly specify dependencies.
This change also prefers the use of short module names. Additionally the
'inherent module dependencies' feature would likely be removed, although
I'm commiting the ported version here in case we'd ever need to bring it
back.
Fixes bug 342806, where a kdesrc-build user notes that "Cloning"
messages are indented while "Updating" messages are not, which can be
confusing.
BUG:342806
FIXED-IN:1.16
Right now kdesrc-build will default to kdesrc-buildrc-sample if no
configuration file is present, but that won't be appropriate now that
KF5 is out. Make the user make a choice instead.
The various READMEs and help texts would probably need to be updated to
match, if anyone wants to help. ;)
This commit makes the kde-build-metadata module a requirement instead of
an option, since the vast majority of runs will require this module now.
Additionally the --metadata-only option is added and documented to allow
for downloading the kde-build-metadata module alone (and make the
--pretend option work afterwards), and kdesrc-build recommends using it
if you run with --pretend and without metadata.
This should hopefully make the first-run use case easier for users.
BUG:337446
FIXED-IN:1.16
I had made some build-system related options not automatically apply to
modules with customized build systems (e.g. Qt, CMake, "custom"). But
this seems like the kind of option we'd want to have in common, as noted
in a bug report to me by Andre Wöbbeking, so make make-install-prefix
apply to all build systems by default if it's a global option.
This can, of course, still be overridden for individual modules or
module-sets.
This is a first-step hack to have non-default build systems ignore
global options which are related to the build system in use (e.g.
compile or make flags, install/uninstall options, etc.).
This should fix bug 331654 (now that I understand it better) and improve
the situation for bug 332789 (which would be the long-term fix when
implemented).
BUG:331654
CCBUG:332789
FIXED-IN:1.16
I was noticing that sometimes Ctrl-C at the TTY doing a kdesrc-build -p
left a monitor process hanging at 100% CPU, not to mention all the
kdesrc-build processes spamming goodbye messages.
It didn't help that I was doing waitpid on an updater PID when that
updater PID had to be 0 by definition.
Either way, I've verified that the forking going on here shouldn't start
a different process group for the shell session, so ^C is already going
to all of the relevant processes. We just need to make sure to catch the
signal and do the right thing (i.e. exit the child process).
What we really want is for this to actually allow many modules I
suppose, but for now you'll need to use the config file with module-sets
to get the same effect.
The last implementation didn't actually match the comments, which was
causing the optimization I committed yesterday to not find some modules
it should have.
Now you don't have to do --stop-on-failure=1.
--resume is documented in the man page and docbook, but basically lets
you resume the last build list quickly without source or metadata
updates, starting from the module that failed. If you want to skip the
failed module, look into --resume-after and --stop-before.
BUG:331941
FIXED-IN:1.16
It's possible for the build process to end far before the update
process, in which case kdesrc-build would wait for the updates to finish
due to waitpid().
Instead send along a SIGINT to cause the update and monitor procs to end
too.
I have a fairly large kdesrc-buildrc, and simply doing a
"kdesrc-build --pretend kcalc" (where kcalc is not directly mentioned in
the config file) was taking 32 seconds to complete, since kdesrc-build
would have to go through each possible kde-projects source of kcalc,
and XML-expand it, in order to find kcalc.
Before this fix, each XML-expansion read the whole XML file looking for
modules matching the search string. Then, everything about the XML file
was completely forgotten.
Now the XML file is read only one time, and every possible kde-projects
module is remembered. We then filter the list of modules each time
there's a request. We can probably optimize this still further, but this
alone is enough to get me down to 3-4 seconds locally.
My KF5 installation doesn't show anywhere near as much improvement (but
then it didn't have anywhere near as many different use-modules entries)
so YMMV.
This makes it safe for things like extragear software to simply
generically depend on kf5umbrella and have kdesrc-build do the right
thing.
Fixes bug 331940, though I know dfaure mentioned it at some point as
well.
FIXED-IN:1.16
BUG:331940
This patch does three things:
1-Adds --install-only for the sake of consistency
2-Adds --install into the usage
3-Makes the CMake (KDE4) build system use make install/fast.
make install/fast only performs the installation of the files
thus avoiding a double compilation.
REVIEW: 116589
With --verbose kdesrc-build will add a description of what dependencies
it thought each module had to the build output for that module.
With --debug the "Visiting module foo" entries will be arranged
hierarchically in accordance with the tree dependency structure.
Otherwise you get an interesting interaction with --refresh-build and
remove-after-install options: remove-after-install removes the previous
build directory, and --refresh-build tries to prune under the new
build directory, which fails since the Perl module that does this first
tries to detect the cwd and fails (since we removed it).
We use a mix of error codes and raw exceptions in the git updater.
Fix this to use the exception objects used elsewhere (and which give
better error messages).
This also simplifies the code by removing error code returns from some
internal functions whose return value is then just converted into an
exception anyways. Easier just to throw the exception directly and
simplify the higher-level functions.
The one nuance here is that installing a git snapshot can fail yet that
should not cause an exception, we'd just fallback to doing a normal
git-clone.
I don't think anyone ever uses it, but I tried just now and I'd broke
it, as the type of the variable holding the return value was wrong.
If "modulefoo" is completely unknown in the rc-file then it will handle
it as a module-set as well, so that you can quickly build something like
'frameworks' if you'd wanted to.
Sayonara, time-tracking. If you need to know elapsed time, run "time
kdesrc-build" (or just look at the mtimes and atimes of the files in the
log directory).
Does about what it sounds like, but quicker. Useful for checking to see
what kdesrc-build is resolving module dependencies to. The beginning
output is intermixed but you can grep for "* Module list" if you want
and everything after will be module names.
Michael Pyne
Jeremy Whiting
Milian Wolff
Raphael Kubo da Costa
David Faure
Alex Merry
Àlex Fiestas
Kevin Funk