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
use the SUBDIR parameters for kde4_create_handbook, so it installs in the proper place
remove the comment related to the issue, and enable the doc subdir
To avoid kdesrc-build build errors, it's probably easiest just to
have a shell CMakeLists.txt which CMake can process and do nothing
with.
At some point it will be used to make the docs build, but right
now the docs install to the wrong directory (as if the name of
the project was "doc" instead of kdesrc-build), so installation
is disabled.
I thought that using the -v flag to git would be sufficient to keep gitorious.org's
git daemon running right when cloning qt-copy, but that output also *must* be redirected
to the tty. This restores the kdesrc-build 1.12 behavior of outputting git modules clone
status to the tty, but only for qt-copy since otherwise gitorious.org's git daemon will
fail for some strange reason.
This hopefully should fix bug 262145, thanks to the reporter for being so proactive in
reporting the bug (including to gitorious) and testing changes and older versions of
kdesrc-build.
BUG:262145
svn path=/trunk/KDE/kdesdk/scripts/kdesrc-build; revision=1214740
kdesrc-build implements the kde-languages option by mapping the 'l10n-kde4'
module into l10n-kde4/{$kde-languages} (e.g. if you asked for de and fr, the
mapping would be l10n-kde4 -> (l10n-kde4/de, l10n-kde4/fr).
This had an issue which I didn't note before with updating the source and
performing builds in parallel: kdesrc-build uses module names to ensure the
source has updated before attempting the build, but the module names were
different when updating the source (plain l10n-kde4) and when performing the
build (the mapped module names)
I solved the issue by not mapping the module names until after the IPC update
was received for l10n-kde4. This fixes bug 262369.
BUG:262369
svn path=/trunk/KDE/kdesdk/scripts/kdesrc-build; revision=1214522
This fix makes it so that the build system for l10n modules is regenerated on every
build (which has the side effect of running the required autogen.sh script). Seems to
work for me, should be in 1.12.1 (when I do finally release that).
BUG:262364
svn path=/trunk/KDE/kdesdk/scripts/kdesrc-build; revision=1213129
The -qt-gif flag was removed from Qt in commit
dfe9084344d73d59f4569c8be6104ce83ae0df95, but it's apparently assumed anyways so the
effect is still the same.
Thanks to Maurel for the report.
BUG:262076
svn path=/trunk/KDE/kdesdk/scripts/kdesrc-buildrc-sample; revision=1213033
kdepepo tells me that the submodules /do/ require some of the special
variables from their supermodule (which makes sense). Turns out I
built-in a way a long time ago to force CMake to run when needed, so let's
just go that route.
This should hopefully complete the support needed for strigi for good until
kdesrc-build uses the projects.xml that is under development.
BUG:261638
CCMAIL:cgiboudeaux@gmail.com
svn path=/trunk/KDE/kdesdk/scripts/kdesrc-buildrc-sample; revision=1210660
Specifically we prefer git pull --rebase (as recommended by dfaure, but jhbuild also
does this now apparently, plus it /is/ a good idea for most), as opposed to git merge.
We still need to do git fetch and git checkout first to setup the remote branches for a
given remote, and then setup the local branch for the remote branch. Oy.
In addition kdesrc-build will try to see if you have local changes, staged or not, and
will run git-stash for you first if that is the case, and then automatically run git-stash
pop afterwards.
Finally, while testing this I noticed that "xx files affected" messages didn't get printed
out when using --src-only (since that's technically printed out in the build phase now due
to async), so that is now fixed as well.
svn path=/trunk/KDE/kdesdk/scripts/kdesrc-build; revision=1210586
Right now that means just grouping the modules into their own module set, and leaving
out the strigi supermodule.
At some point I may allow module-sets to have their own names so that you can do
"kdesrc-build strigi" from the command line, but for now this will have to work.
BUG:261638
svn path=/trunk/KDE/kdesdk/scripts/kdesrc-buildrc-sample; revision=1210570
Now more possible errors are shown (such as using use-modules outside of a module set,
using global options inside a module, etc.), and other minor improvements should be there.
svn path=/trunk/KDE/kdesdk/scripts/kdesrc-buildrc.xml; revision=1208525
move of Phonon to git.kde.org.
Thanks to Eike Hein for the heads-up.
CCMAIL:hein@kde.org
svn path=/trunk/KDE/kdesdk/scripts/kdesrc-build; revision=1208506
instead of always checking results and then calling exit if there were problems.
I had previously avoided the use of "die" since the error message claims it's a
kdesrc-build bug, so I migrated over a later hack I'd put into place to tell
apart actually Perl exceptions throw due to bugs from intentional runtime error
exceptions thrown by kdesrc-build.
svn path=/trunk/KDE/kdesdk/scripts/kdesrc-build; revision=1207660
occurred to me that I broke it (the repository special feature, the whole point
to module-set, was broken). That is now fixed, and the kdesrc-buildrc-sample
file is updated to reflect how to use module-set currently.
svn path=/trunk/KDE/kdesdk/scripts/kdesrc-build; revision=1207658
Michael Pyne
David Faure
Yuri Chornoivan
Montel Laurent
Script Kiddy
Stas Verberkt
Pino Toscano
Raphael Kubo da Costa