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
OK, so I had the idea last week to remove the repository name from the module-set
parameter, and add the ability to have the 'repository' option automatically use aliases
defined by git-repository-base. dfaure seemed to like that, and I've heard no other
negative feedback, so I've gone ahead and implemented that. (The old style is a syntax
error instead of me being nice and accepting it since it's never been part of a release).
So now, something like this should work:
module-set
use-modules automoc akonadi attica # and etc.
repository kde
end module-set
For a "kde" repository previously defined in a git-repository-base in the global section.
You can throw any other option into that module-set, and it will be applied to all of the
modules (that's been true for about a week now).
While I was at it, I fixed the source update for git modules to actually give
the "Updating" or "Cloning" module message similar to how svn modules are
noted, and I've added a warning if a module-set with no use-modules is declared.
I'd like for this to be all the new features before the next release, so please keep
testing!
svn path=/trunk/KDE/kdesdk/scripts/kdesrc-build; revision=1207654
kdesrc-build use its internal 'git remote' name to avoid messing with the user's
git-remote settings).
If you don't like it, please manually change 'origin' (or whatever git-remote you're
using) to point to your desired repository, or lobby for me to have kdesrc-build just
always use origin. Either way. ;)
svn path=/trunk/KDE/kdesdk/scripts/kdesrc-build; revision=1207651
As recommended by dfaure, a module-set will allow options to be set within the set, and
these options will be applied to every module that kdesrc-build defines based on the
use-module statement.
It remains possible to individually override options for a single module by making a
module declaration after the module-set is defined.
As always, please test. In addition, I am thinking of removing the repository parameter
to module-set, and compensating by allowing a previously declared git repository base to
be used in the existing "repository" option. e.g. something like
module-set
repository kde-git # Defined earlier
use-modules <modules>
cmake-options -DCMAKE_BUILD_TYPE=debugfull
end module-set
CCMAIL:dfaure@kde.org
svn path=/trunk/KDE/kdesdk/scripts/kdesrc-build; revision=1204574
This commit adds two options (not yet documented in the DocBook):
1. git-repository-base, which defines a new repository alias (kde-git in the sample file)
In order to actually use this repository alias, you can use a new type of module
(unimagineatively called a "module-set") like so:
global
...
end global
module-set $repo_name
use-modules <list of git modules e.g. akonadi attica soprano k3b etc.>
end module-set
No other options are supported in a module-set at this point. kdesrc-build treats a
module-set as if you'd simply manually declared a new module for each item you passed
to use-modules, and sets the "repository" option for each new module to the base URL
(as determined by repo_name), with the module name tacked on.
kdesrc-build will filter any trailing .git off of the virtual module name.
If you still want to add options for a module, you can simply manually declare a module
of that name after the module-set, and choose options there (it won't change the build
order though).
Hopefully this makes it that much easier to use the plethora of git modules that have
been getting successfully transferred over to git.kde.org. PLEASE let me know if I've
broken something here or otherwise improperly implemented it. CC'ing dfaure since I
figure he'll be interested and/or have feedback.
CCMAIL:dfaure@kde.org
svn path=/trunk/KDE/kdesdk/scripts/kdesrc-build; revision=1204410
and your test results will be uploaded to http://my.cdash.org
CCMAIL: mpyne@kde.org, nicolas.alvarez@gmail.com
svn path=/trunk/KDE/kdesdk/scripts/kdesrc-build; revision=1198713
* kdesrc-build no longer prepends entries to the path that it normally would (such as
$KDEDIR/bin, $QTDIR/bin) if it finds that those entries already exist in the system's
environment variable. (This affects PATH, LD_LIBRARY_PATH, and PKG_CONFIG_PATH for the
most part). The reasoning is that we always want system path entries to be the
least-preferred, so promoting them to near the beginning of the environment variable
inadevertently could have the ill effect of mixing system resources with what we're
trying to build. This was noticed by Jeremy Whiting who is using a system Qt (in /usr)
and had to hack around kdesrc-build to make it work.
* The 'binpath' setting in its first incarnation simply set PATH directly to that value,
so that the then-kdecvs-build could work fine from cron. It later took on a
default value of $PATH, for ease of interactive use, and even later
kdesrc-build changed the way we construct environment variables, so that now
it is PATH=$binpath:$implicitly_set_vars:$PATH. But binpath itself contains
$PATH, which makes this incorrect. Now binpath defaults to nothing, which
should help ensure a correct build, and setting binpath simply prepends those entries
to the front of PATH without clearing the ones already set. (If you need to actually
clear entries, you'll need to do so at the shell or use some kind of wrapper script).
svn path=/trunk/KDE/kdesdk/scripts/kdesrc-build; revision=1198244
so that they can be used even from a KDE running in another prefix (http://markmail.org/message/4p3krovtnzwx35zd)
svn path=/trunk/KDE/kdesdk/doc/scripts/kdesrc-build/; revision=1188169
Pino Toscano
Stas Verberkt
Michael Pyne
Script Kiddy
Raphael Kubo da Costa
Laurent Montel
David Faure