E.g. Running "kdesrc-build kdeedu" with a kdesrc-buildrc containing
module-set
repository kde-projects
use-modules kdeedu
end module-set
would give a runtime exception, even though kdeedu expands to a valid
set of modules. The code here is too restrictive, looking for actual
specific *modules* (i.e. assuming that the use-modules entry specifies a
specific module instead of an implicit wildcard entry).
BUG:339965
FIXED-IN:1.16
Bug 341159 complains about kdesrc-build-setup not setting up the kde:
git prefix, but kdesrc-build-setup itself never even calls git, it just
creates a .kdesrc-buildrc and exits.
However the currently recommended way to start out kdesrc-build is to
run "kdesrc-build --metadata-only" for the first build to setup
directories and download required data, while still letting a subsequent
"kdesrc-build --pretend" do something useful. kdesrc-build didn't setup
the kde: prefix in time to support --metadata-only, and I'm willing to
bet that's what the user was encountering here.
So, setup the git configuration before the first time we can use git.
BUG:341159
FIXED-IN:1.16
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 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.
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.
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.
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.
I was so convinced this was already the case that I told dfaure that was
how the code worked and so it would be hard to find the bug he was
experienced. Whoops.
The corrected code now employs dependency resolution before the
second-pass --resume/--start handling, so that kdesrc-build should still
build modules after their dependencies are built.
This did give me the opportunity to clean up the metadataModule TODO
finally. Now there really is only one place that tracks whether we use
metadata or not, just like it should be.
The recent port to Getopt::Long broke the ability to use --foo=bar type
of options (where <foo> is a global option name known to the build
context). It also replaced the --module,foo=bar options with
--set-module-option-value=module,foo,bar.
While it's possible to use the latter syntax for global options (by
using 'global' as the module name) that is undocumented and may not work
forever. And either way, --foo options did use to work, and I noted it
was broken in the refactor.
So now that someone else has noticed I've reimplemented the feature.
It's difficult to do entirely from within Getopt::Long since the
documentation for that module gives you essentially one catch-all, which
only supports *non-options*.
So what I've done instead is to have kdesrc-build dynamically introspect
its list of global options and flags and then add them to the list of
valid options we pass to Getopt::Long. This also should mean that we
don't need to pass 'pass_through' as an option to Getopt::Long anymore,
though we'll see.
This code path won't be used for options that already have a command
line option (such as --async/--no-async) so that is still a misfeature
compared to how it was before, but I guess it can't be perfect. =D
I've tried to ensure that "flags" support the 'false' value to mean
boolean false, but be careful to pass false or 0 if that's what you
mean... specifying --dont-foo without giving it a value defaults it to
true.
BUG:330386
The return result obtained from the waitpid($monitorPid) will account
for a failure of the update process and force $result to be 1 (an error
status).
If the update was successful then $result is unchanged, which means if
the build process had failed, then $result would still indicate failure.
That didn't work due to the addition of the 'my', which masked the
top-level $result.
BUG: 330388
Add a specific config file grouping (which acts just like a module
declaration), to allow for specifying options to override a
previously-declared module.
The use case here is for a module-set: You can specify options which
apply to an entire module-set when declaring the module-set, and then
override those options with any changes in a later "options"
declaration.
These declarations can stack too, so this can also be useful for
multi-level file includes (but this is less useful since an "options"
declaration requires a specific module, it doesn't work on module-sets;
in that case you'd want to have the different module-sets in your
most-specific included config files instead of in a base file).
Tested on my personal test case for bug 321883, and on a --pretend run,
and with a bug 321883 test case modified to not pre-declare the
overridden module first.
Example:
module-set kde-mm
repository kde-projects
use-modules kde/kdemultimedia
end module-set
options kmix # Not mentioned before this line
branch KDE/4.11
end options
In this case kmix would use KDE/4.11 branch while juk (and the rest of
kde-mm) would use whatever the global branch or branch-group was
(probably 'master').
BUG:321667
Proposed in http://lists.kde.org/?l=kde-commits&m=138887053920094,
though I am proposing that the common dependencies be stored in
"dependency-data-common" instead of "dependency-data-general".
In addition we would unilaterally choose a branch group now, falling
back to the existing 'use-stable-kde' option if needed.
Note that due to the way the code works, if you don't set
use-stable-kde, and don't set branch-group, you'll end up with
latest-qt4 for now. I would imagine this will change in the future
though!
As opposed to making them relative to script location, original rc-file,
initial cwd, or similar. This allows for whole directory trees to be
moved around if need be as well as long as the internal links remain
consistent.
I've tested this on a sample here and also on the provided test case
with the bug and it seems to work well although I have not had time to
run through a whole build, merely the --pretend sequence.
BUG:329444
FIXED-IN:1.16
Handling options for the modules generated from a module-set has always been
especially clunky, and at some point even the hacks failed and it became
impossible to do things like setting an option for a specific module picked out
of a larger module-set.
E.g. the idea was always that the following would work:
module-set foo
repository kde-projects
use-modules kdelibs kde-workspace kde-runtime
cmake-options -DCMAKE_BUILD_TYPE=Release
end module-set
# Override the above, but only for kde-runtime
module kde-runtime
cmake-options -DCMAKE_BUILD_TYPE=Debug
end module
Probably I should have named "module" as "options" or even "override" (and
that's still feasible), but in any event this has been broken for awhile:
whenever kde-runtime is built it would end up with a Release build type instead
of a Debug one.
Worse yet, the second mention of kde-runtime was handled as a separate module.
Usually this duplicate module was weeded out by accident during the dependency
resolution phase, but that leaves open the question of which internal Module
object was the "winner"... now we can't even rely on the option handling being
predictably broken.
This was partially helped by c565d4c which at least prevents the code from
spitting out duplicate modules from within a given module-set (which is quite
easy to do by accident with kdelibs).
This commit reorganizes the command line and option reading code to do the
following:
- Add a "pending option" tracker, to hold option values that should be applied
to a named module, if one happens to be created, either via explicit
module-set expansion (e.g. if you ask for nepomuk-core or nepomuk-widgets) or
via implicit expansion (e.g. if you ask for kdemultimedia, you get juk and a
lot of others).
- Add a "selector" method which is responsible for translating module entries
on the command line into appropriate module-set or module selections from the
Modules and ModuleSets read in from the rc-file.
- Pass a subroutine to the module-set expansion method and the selector method
to ensure that any new Modules created as a part of either process are checked
for pending options (either from the rc-file due to the "override" module
method, or from the command line.
- While I was digging it out I made the long-overdue switch to Getopt::Long
away from my custom option parser. There are a couple of minor features lost in
this process but if they are needed I can add them back.
Now it should be possible to override options for individual modules within a
module-set. However as before, the module you wish to override *must* have been
mentioned somewhere before in a use-modules entry so that kdesrc-build can
recognize that it must hold onto those option values for later application. It
is still safe to mention a kde-projects module and its superset, they will be
re-ordered if necessary.
BUG:321883
FIXED-IN:1.16
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.
Michael Pyne
Jeremy Whiting
Milian Wolff
Àlex Fiestas
Kevin Funk
David E. Narvaez