Specifically, when we have a non-master global branch, the new feature
to filter out module-set modules that don't have that branch was being
mis-applied to kde-build-metadata just to get some flags set right.
Instead, set the flags needed directly and skip the filter.
No need to re-add /usr if it's already in PATH (and doing so can even
lead to changing a user's preferred PATH order, even though it's
possible to work around that issue by playing with user_path in
.config/kde-env-user.sh).
BUG:312122
FIXED-IN:1.16
The most noticeable effect is probably that it should be damn near
impossible not to have automoc build first now, at least in comparison
to other kde-projects modules. It also should take care of the vast
majority of the code needed for bug 312324. Still needed is handling for
Qt/Qt5.
BUG:312324
FIXED-IN:1.16
We now read in and should be able to handle branch-specific dependencies
and module dependency exclusions.
For full support we still need to find a way to properly handle Qt vs.
Qt5 modules (e.g. for phonon Five and automoc).
The last commit's first attempt had an error where the kde/foo/* syntax
would be stripped to '*', which the KDEXMLReader actually understands
perfectly. Unfortunately a bare '*' reads in all modules, including
websites and other unpleasant things.
I only caught this by chance, so add a sanity check to make this an
error in case I miss it in the future.
Although a module like kde/kdeutils/kcalc will eventually end up with a
$module->name() of "kcalc", the module starts off with whatever the user
typed in for its name in the use-modules declaration.
This makes it difficult to override its options in a later module / end
module declaration (as its documented to do). E.g. the kcalc branch for
the following should be "KDE/4.9".
module-set
repository kde-projects
use-modules kde/kdeutils/kcalc
branch KDE/4.10
end module-set
module kcalc
branch KDE/4.9
end module
*** Important ***: There's no way for kdesrc-build to know when parsing
that the "module foo" is supposed to override a module-set module if it
hasn't seen the foo declared yet. In this example, if you simply did
"use-modules kdeutils" then you may end up with a svn-based kcalc (since
it's a "new" module without a repository declaration).
I'm not sure right now if I'll decide that possibility needs to be
handled as well so I'll leave the bug open. But it should be possible to
override any module-set module that is named with this fix.
CCBUG:299415
Commit 63e21e9e1b filtered only based on a
module-set branch. This causes problems with global branches that might
have the same issue so we'll just filter out all such modules.
We probably need to use the scm()'s getBranch() method to have a 1:1
check in the presence of use-stable-kde, but even that should work due
to the way branch handling is performed with use-stable-kde (which
should always pick existing branches).
BUG:307694
This should fix the big ugly error messages for this particular
scenario. The code in question is trying to determine a good branch name
that it can use, which means it need to verify that the requested branch
name *doesn't* exist. This would correspond to an exit code of 1 for the
given git command.
In pretend mode all safe_system() calls give an exit code of 0, so it
appears that there are no safe unused branch names.
Since even in pretend mode the source directory should exist in this
code path I switched to use a system() call (with the correct full
branch name to boot).
I'm not sure the other part of the bug is fixed (i.e. checking out a
local branch immediately after cloning or whatever dfaure was seeing) so
I'll leave open for now until I can do further testing.
CCBUG:311758
Or in other words, command-line modules that are "guessed" kde-project
modules (and eventually confirmed to be kde-project modules) do not have
their options loaded from the rc file as they would if no modules were
passed on the command line. This could be highly annoying when
considering things like branch switches.
It's rather inefficiently fixed for now by brute-force "proj-expanding"
all modules available in the configuration file since that's the easiest
way to propagate module-set options into a list of modules.
Unfortunately there's massive low-hanging fruit for optimization here.
BUG:312096
FIXED-IN:1.16
In the process of trying to plan out the best way to fix the issue where
module names passed on the command line that are implicit subprojects of
a kde-projects module go unrecognized, I decided that I needed a better
way to navigate the API.
There is a Doxygen::Filter::Perl available which seems decent as it
allows one to use the nice and familiar Doxygen tool, but it seems a bit
buggy still.
NaturalDocs is a tool which seems better able to cope with kdesrc-build
and its code, although it prefers comments to be formatted unlike the
normal qdoc/JavaDoc syntax used by Doxygen. However it's not that much
different and is easier to install and use otherwise. Maybe when I get
some time I'll go ahead and properly convert everything.
Skip the kde-build-metadata update phase if --no-src is passed, or if in
--pretend mode. I know I've noticed this myself and even heard
complaints about this behavior but surprisingly I can't find an open bug
to close.
It's easiest to describe by giving the test case:
module-set kde-workspace-utils
repository kde-projects
use-modules kde/kdeutils
branch KDE/4.9
end-module-set
This pulled in all modules available under the kde/kdeutils virtual
path, including print-manager (a program only available from KDE/4.10
on). When kdesrc-build tried to switch the branch of print-manager to
KDE/4.9 it failed after cloning.
Now we don't even try cloning print-manager (or in general, any module
that doesn't have a branch specified for the whole module-set).
To be clear, this is the only level of detail we look at for filtering
at this point: Is a branch option given for the module-set, and if so we
filter out non-matching modules that would be implicitly selected.
BUG:307694
FIXED-IN:1.16
The merge was mostly straightforward. I ran
git log --oneline $(git merge-base master modularize)..master
to see all changes applied to master while this topic branch was being
worked in order to ensure they weren't accidentally missed:
83bee36 SVN_SILENT made messages (.desktop file)
f2299f1 xsession: Disable session driver installation by default.
05f8745 Remove undefined method for default module handling.
2 were merged correctly, the session driver default had to be
re-committed to the appropriate module.
Conflicts:
kdesrc-build
This can be used as a run-time check later to ensure that kdesrc-build
finds compatible versions of its component modules (though that isn't
done yet).
This may yet be moved to the kdesrc-build-setup script instead so
disable this by default so that those tracking kdesrc-build git don't
have to necessarily deal with this handling. It can still be manually
enabled.
This will cause a conflict with the 'modularize' branch, which should be
resolved by merging this change into the ksb::BuildContext Perl module.
This was changed some time ago to pull from kdesrc-buildrc-sample if no
other config was defined, which ended up removing the method being
called here. But I didn't remove all usages of that method, which was
caught by a user yesterday.
This was the last remaining module embedded into the main script file,
so if we leave it here this completes the transition of modules out of
the main script.
This makes modularizing the build systems less annoying. I was surprised
that creating a class using a scalar variable instead of the bareword
works without tripping warnings about using references, but it works
just fine in testing here, test suite still passes.
This also required updating the test suite, which rather surprisingly
doesn't seem to need further modification (probably since the test-suite
includes kdesrc-build as a prerequisite, which sets up the @INC
modifications required).
Michael Pyne
Script Kiddy
Daniel Laidig
Montel Laurent
David Faure