Thiago, let me know if kdesvn-build is still warning you about module locations afterwards.
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=529220
selected, instead of requiring weird hacks in the config file to use the snapshot.
e.g.
module kdelibs
branch kde4-snapshot # Use the branches/work/kdelibs4_snapshot stuff.
end module
Make the snapshot the default for kdelibs, which should help with the Coverity stuff.
Don't try to download a snapshot if override-url is in effect for a module.
Update the sample file to match, including a comment at the use-stable-kde option to warn
the user to also update the kdelibs options.
Touch up the pretend mode output a bit.
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=529207
could happen if the user were setting qt-copy options from the command line.
Also, my last commit had code to remove CMake cached information before running
cmake again, mentioning here so that I don't forget to add that to the
changelog for the next kdesvn-build release.
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=526654
Now if a module has a different kdedir than kdelibs, the kdelibs kdedir setting will be
appended to the end of KDEDIRS. i.e. if kdebase had kdedir = /usr and kdelibs had kdedir =
/home/kde/kde, the KDEDIRS for building kdebase would be "/usr:/home/kde/kde"
I'm hoping this helps to fix or at least identify the problem going on in bug 122843.
CCBUG:122843
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=526651
someone else.
I can't actually test this because Perl seems to never let this happen on my
system (even when kdesvn-build is setuid root, it executes with the euid and
uid of my local account) but it seems prudent nonetheless.
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=523441
This adds two new options: use-cmake (but this one will go away once CMake is the only
option for KDE 4), and cmake-options (but I think I will find a way to make it so you never
need to use this).
Also added is a new command line option, --run (which runs the given command using the
internal kdesvn-build environment).
The documentation has also been updated.
The check to see whether unsermake needs to be downloaded is also very slightly improved.
Finally, kdesvn-build does not set KDEDIR, it sets KDEDIRS. Score one for removing deprecated
interfaces...
I think I've caught most of the places where the fact that we're using CMake is an issue
(i.e. do-not-compile, inst-apps, trying to make apidox, cmake-options adding to
global options like configure-flags does, etc.) If I haven't, please e-mail me
or file a bug against kdesvn-build.
Seeing as how this is the first release with support for CMake, it should come as a surprise
that it may not work! So, please test now so I can make a real 1.1 release in the next week
or so.
svn path=/trunk/KDE/kdesdk/doc/scripts/kdesvn-build/; revision=523429
it should not be that big of a deal, plus we no longer have source in the qt-copy build
directory for Qt 4.
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=520456
- use-qt-builddir-hack is no longer optional (but is only required for Qt 3).
- The configure flags are identical since kdesvn-build adds -prefix automatically.
- apply-qt-patches seems to work all the time now, so re-enabling by default.
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-buildrc-sample; revision=520452
the -prefix option to the qt-copy configure script and runs make install for qt 4. Qt 3 is
still fully supported, except that use-qt-builddir-hack (which makes kdesvn-build force
qt-copy to be builddir != srcdir) is no longer optional (it is always enabled).
As always with any sort of change to the dance kdesvn-build plays with qt-copy, PLEASE TEST.
I even compiled (and installed for qt 4) both 3.3 and trunk qt-copy and it seems to be
alright. I do still need to test the case where qtdir == $srcdir/build/qt-copy though.
Also, configure flags are no longer ignored for the l10n module.
BUG:116621
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=518746
instead of kdesupport trunk (which is now based on Qt 4) when building KDE with
the use-stable-kde option enabled.
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=505088
initial checkout. This doesn't work for kdesupport yet because the snapshot at kdesvn-build.kde.org
is improperly tagged.
But for modules that are already available as a snapshot, this can represent a significant
speedup for the initial checkout. I'd appreciate it if users could test this out.
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=503728
Remove the --resume option, it doesn't make much sense now that kdesvn-build will completely
fill out the status file whenever possible. --resume-from is still available.
Reorganize copyright header to put it at the head of the file.
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=491948
KDE 3.5. With this option enabled, kdesvn-build will act as kdesvn-build 0.97.x does,
defaulting to versions of modules appropriate for building KDE 3.5.
Also fixed the default value of 'apply-qt-patches' for Qt 4.
Also made the branch and tag options work with qt-copy, now you don't have to set
module-base-path to use Qt 3.3 anymore.
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=491941
the build directory itself so this should work with dfaure's system too. ;)
A few assorted bugfixes thrown in for good measure.
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=490168
up on kde-devel that unsermake isn't suited for this task.
To not be completely useless the warning message includes a link to EBN.
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=488845
It is controlled by the global kde-languages option, as described in kdesvn-buildrc-sample.
e.g.
global
kde-languages el # greek
....
end global
If I remember right you can also control this via the l10n module directly (using
module l10n with checkout-only) but please don't. :)
Internally this is implemented in terms of the l10n module, so if you just want to update
your translations, it is as simple as:
% kdesvn-build l10n
or
% kdesvn-build l10n/$LANG
PLEASE PLEASE PLEASE test this so I can make a release later. :)
In my testing l10n/de broke but l10n/fr worked (but that was last week).
I'd like to thank levipenumbra for providing an initial patch for the support.
Also included because I am lazy are some pretend fixes and a debugging chdir()
call.
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=484473
I can make the build dir for a given module a symlink, and kdesvn-build will
keep the symlink instead of replacing it with a real dir.
This helps when partition is getting full :)
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=484350
Add a default "kde-langauges" option (defaults to empty). This is unimplemented but I will
try to implement this in the next week.
Correct the munge_lists() procedure to clear the checkout-only option correctly if more than
one module needed it. (munge_lists() is used for the shortcut on the command line e.g.
doing kdesvn-build --svn-only kdelibs/khtml to update only kdelibs/khtml).
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=481684
execute a command, which will prevent kdesvn-build from getting hung at the terminal by a
command trying to read some input:
What this entailed was:
* Preventing sudo from opening a direct connection to terminal. This was easy, as sudo has
a command line switch to do just that. Note that this won't work for other programs used
as the make-install-prefix command.
* Preventing subversion from prompting the user while still allowing the checkouts/updates
to succeed. This was harder, and could be a bit controversial.
Basically the big stumbling block for subversion is that because the SSL certificate for
svn.kde.org is unsigned (and will always be accessed at least once), subversion will
(rightly) prompt the user to see if they trust the site. But this breaks non interactive
builds (which is what kdesvn-build is for, after all). svn has a nice --non-interactive
switch but that defaults to rejecting the cert, which would make kdesvn-build useless.
So, what I've done for that is added code to install the appropriate signature file if it
is not detected prior to performing the update. This is, of course, bad for all the obvious
reasons:
1. It is choosing for the user to accept svn.kde.org (I don't consider this so bad really)
2. Should the SSL cert for svn.kde.org ever change (and still be invalid), then people
will have no way to allow svn to work without running it manually. I have a mechanism
to avoid redirecting stdin in case this happens however.
3. This is very dependant on subversion not changing file locations, signature algorithms,
etc. So, we're not future proof here.
However, I'm tired of waking up and seeing kdesvn-build still trying to compile kdelibs or
something because it wants to know if I want to change the mode of a file. Uh, thanks. So,
in it goes. I'm open to suggestions that are implementable for solving the svn thing in a
better fashion.
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=477110
* Simplify qt-copy default flags.
* Some comment corrections.
* Correct a call that read debug print (should have been just debug)
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=475042
restrictions that kdesvn-build places on global options.
Now it is possible to override things like source-dir, qtdir, kdedir, and
svn-server on a *per-module* basis. If you do this and break your install,
please don't blame it on me. =D However it should make it possible to do
some cool things.
In addition, don't try to grab a lockfile when being run in --pretend mode. So
you can always run kdesvn-build -p even when kdesvn-build is already running.
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=457211
For instance, doing this has been valid for awhile:
global
cxxflags # cxxflags set to ""
end global
But empty options were ignored by kdesvn-build.
Also remove architecture-specific -march option from default cxxflags, as it
breaks on 64-bit systems (not to mention PPC). It is still present in the
sample file, although the user is told they can edit it. ;)
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=453342
created only when make -f Makefile.cvs was being run. Since the symlink is
removed before the update is done it needed to be created whenever the module
is built.
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=453033
Michael Pyne
David Faure
Dirk Mueller
Laurent Montel
Nicolas Goutte