well since I just noticed that snapshots for those modules are being made.
Also have --pretend output indicate that the snapshot download will be attempted (although it is
assumed to fail when pretending)
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=910751
them all to consistently ignore stderr output. Also I'm not using all the core modules from Perl
5.8 yet, still have a ways to go on that though....)
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=910737
The root cause of the problem was that when you had more than one option on a single cmake-options
command that it was not getting split into a list properly.
The root cause of *that* error was that the regular expression I used to perform the split
(without splitting around double-quotes) failed with leading whitespace. I didn't do testing for
that case but that it how the function ends up getting called in kdesvn-build.
In addition to the bug I've added quotes around individual command parameters for log_command() to
make future instances of this type of bug (improper splitting) more obvious.
BUG:172719
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=910294
* tag and branch options no longer append the module name when generating the
SVN URL, since many tags and branches are no longer tagged in that style. If
you are using a module that needs the module name in the tag you can still
append it manually. i.e. tag 0.7.8/module-foo instead of tag 0.7.8
* Likewise no longer append the module name when using the module-base-path option.
* Change get_repo_url() to get the on disk repository URL for a given module.
* Add a warning if the module base path seems to have changed due to these changes
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=909539
"module-base-path branches/KDE/4.2" for all kde modules,
"tag kdesupport-for-4.2" for kdesupport (because I used a kdesupport subdir in there),
but unfortunately there's no nice solution for qt-copy, it's in branches/qt/4.4 (but without a qt-copy subdir),
so the "branch" or "module-base-path" solution doesn't work, only override-url does (which is really not as nice).
Michael, could there be a way to set some "base path where the module name is NOT appended" somehow?
I can only think of a new (per-module) option like "svn-path branches/qt/4.4"...
CCMAIL: Michael Pyne <mpyne@purinchu.net>
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-buildrc-sample; revision=906770
Perl bug 61964. May not actually be their fault but I'm tired of digging through the source to
identify exactly what's trying to call ioctl() on a file.
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=906322
testing, but this is still a fairly embarrassing bug to make it to a release. :(
Guess I should heed the motto of "Slow is Fast" and stop rushing myself.
The cause of the bug was moving around the definition of $script. Later code in the function
(inappropriately) used the value of $script which used to coincidentally be correct.
As a bonus though the debugging for this also uncovered a long-hidden bug in the venerable
get_option subroutine which would cause qt-copy's configure to fail if the configure-flags were
empty.
Also persistent option reading is given a sane default, which should hopefully fix the other
build failures.
BUG:172288
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=868757
cmake or configure (for qt-copy/KDE 3) if the flags changed (whether directly or indirectly).
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=867955
cmake. This allows users to add options with embedded spaces.
Only double-quoting is supported, without backslash-escaping inside the double quotes.
Patch provided by Alain Boyer (bug reporter), thanks!
BUG:171814
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=867894
kdesvn-build has supported an automatically generated symlink in the log
directory called latest for awhile now, which puts you in the log directory
for the last build run.
Now, instead of symlinking latest to the last build run, latest holds a
directory of symlinks. Each symlink is named after the module concerned and
links back to the last build run for that module. That way you always have
easy access to the logs for the last build run of a module without having to
run find or anything crazy.
You should find that using it is effectively the same unless you have tools
of your own that depend on $logdir/latest being a symlink.
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=854548
modules with respect to the global branch setting.
For example if you set "branch 4.1" globally and have no branch preference for kdesupport you'll
get trunk for now (later to be changed to the mythical stable-kdesupport-stuff tag). For phonon
you'd get 4.2, etc.
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=854184
still too used to autotools apparently). So, if the user asks to build phonon/trunk (remember
phonon is a virtual module in kdesvn-build) handle that appropriately as well.
So:
phonon branch 4.2 -> /branches/phonon/4.2/phonon
phonon trunk -> /trunk/kdesupport/phonon
so either way it should work now. I will update the sample rc file shortly.
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=851149
Also remove a now unnecessary line which I neglected to remove entirely when excising apidox support.
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=844539