GitLab

This allows for having a "shell setup" script usable everywhere and
managed by kdesrc-build, and yet still allowing the user to add their
own settings automatically.

This "shell setup" file is then used by the "session setup" script, also
managed by kdesrc-build.

I think we're getting close to something generically usable by all.

So I relented and added an auto-backup if --delete-my-settings is used.
Hopefully this avoids introducing big problems for users.

This implements the command line option mentioned in the last commit, to
allow for overwriting .xsession (and possibly .kde-env-master.sh, if it
exists).

Probably would still be a good idea to make a backup though.

Currently we install after printing out the various failure category
results.

There is a "--delete-my-settings" option that is mentioned to override
the file collision detection, but it's not actually implemented. We do
automatically ignore file collisions if the previous version was
installed by kdesrc-build, we use md5 digests to detect this case.

I will still need to rearrange the variables so that *only*
kdesrc-build-controlled changes are made in kde-env-master. E.g. KDEHOME
might be changed by the user... but then kdesrc-build will always
complain that it wants to overwrite it.

We're getting close though. :)

dfaure reinforced a point I was thinking after doing testing on my
system... the environment variable-setting portion of the script needs
to be factored out into its own script so that it can be sourced easily
from login profile setup, shell setup, etc. and not just used from the
xsession startup.

It's still not active (but the code is used in the test suite), will try
to work on that tomorrow assuming the sequel to "Perfect Storm" about to
strike here in DC leaves me with power...

I somehow missed the case of "branch option not ever set" by using the
getOption method to grab the git branch instead of the specific build
system "getBranch" method that had been used before. This led to build
errors trying to dereference an undefined variable.

My apologies for the trouble.

This makes the 'tag' option allow for checking out a given git tag for a
module (which is enforced by using refs/tags/$foo when passing to git).

Additionally, the 'revision' option has been adopted for git modules as
well, to allow for checking out any other git "tree-ish" that git
supports (i.e. anything supported by 'git checkout $foo').

Both options should leave the source directory in a detached HEAD state,
although kdesrc-build will adapt as necessary with each source update.

The auto-stashing is still attempted for both types, and a failure to
apply an auto-stashed change will cause the module to fail to build.
Ensure you're in a clean working directory if you want to avoid issues
due to this.

The test suite continues to pass (not that it's very extensive).

BUG:308493
FIXED-IN:1.16

This partially implements bug 308493. To fully implement it will be
required to handle the case of an already-checked-out module (though
prepatory work is already complete).

CCBUG:308493

To support git tags we need to take different semantic actions (as
checking-out a git tag leaves you in a detached-HEAD state where
git-{pull,merge,rebase} don't apply). To prepare for having different
methods for these different semantics I'm factoring out the git-remote
setup into a separate function, and removing the needless support for
lists of possibilities. Nowadays kdesrc-build only cares about origin,
though if you want to bring your own remote that's fine, kdesrc-build
will find it.

SVN_SILENT

this commit was automated; please revert if it causes trouble
for details see http://lists.kde.org/?l=kde-doc-english&m=134965352825792&w=2

SVN_SILENT

kdesrc-build has long supported using a file '.refresh-me' in a build
directory as a flag to treat a module being built as if the
'--refresh-build' command line option was passed for that module.

As suggested in my last commit message, this commit will automatically
create that file if the configure/build-system-setup phase of a module
build fails. This way even if I choose wrong on which filename to look
for to determine a successful build, there will still be a way for
kdesrc-build to easily tell that it should start all over next time.

We used to use "Makefile" for the KDE/CMake build system to determine
when CMake was successfully run, but the commit to allow for
custom-build-commands replaced that with CMakeCache.txt.

This choice was incorrect, as CMakeCache.txt is always generated, even
if CMake fails. cmake_install.cmake seems to be a better choice (I've
confirmed it's generated on success with both ninja and Makefile
generators).

It's probably still a good idea to explicitly touch .refresh-me in the
build directory if the configure phase fails. I leave the build
directory intact if configure phase fails to allow for "post disaster
investigation" but we should always re-run configure phase in this event
on the next kdesrc-build run.

A few minor related changes are included. E.g. we actually want to pass
along blank lines, so remove that check (which didn't work anyways as \n
was still present).

We replace that with a simple filter in the template installation
process to allow there to be source lines in the base template that
don't get passed to the installed result. This allows for shell script
that prevents running the full command suite in the base without
affecting the installed script.

It is required to be able to actually run the base script as the "set
-u" check for unset variables doesn't work when "set -n" (syntax check)
is in use. These set commands can be passed directly to /bin/sh to have
them in effect when the script starts (and are both part of POSIX and
seem to work even with busybox sh).

Additionally, the path_add function needs to actually check for unset
variables now. Luckily there is existing Bourne shell syntax for that.

The observant reviewer will note that the testsuite does not currently
pass because there is a mispeled lib_suffix in the base, that will be
fixed in the next commit.

This isn't turned on yet (the testcase just tries to run the function
without exceptions), but this would be the base for a feature to install
the new sample .xsession file for the "Custom session" login option for
most login managers.

The base .xsession was graciously provided by Michael Janses (of
build-tool fame). I've simplified it a bit for kdesrc-build usage and
tried to make it compatible with less featureful shells. The eventual
idea is that it can be used with kdesrc-build-set and/or kdesrc-build so
that you can run the setup script, kdesrc-build, and be able to login to
your new KDE install.

This could be annoying for Qt if it takes 10 minutes to fail, but
there's already a warning message for this case. For the rest, it's
most likely that making things work at all will require a
--refresh-build anyways (e.g. if CMake was run but didn't generate a
Makefile).

Although 'parent' is a core Perl module, it is not installed by default
on Fedora. :( :(

I am now aware of no major build system that couldn't be supported by
kdesrc-build...

The excuse in this case is the same as for last commit, namely to allow
for libraptor-2 support (their build system has CMake support, but it's
incomplete).

This is necessary in situations where the source includes more than one
build system (especially when only one of those actually works but
kdesrc-build auto-detects the other). The current example would be
libraptor.

It's pretty hard to check for a conflict-detected field in an exception
object when you're overwritten that exception object with a simple
string.

This small buildsystem allows kdesrc-build to bootstrap CMake (from git,
obviously) onto a system that does not have a recent-enough packaged
version of CMake.

The "bootstrap" process is treated as module configuration, so
"configure-flags" is the relevant option (don't worry, those won't be
inherited from global configure-flags). The rest of the build/install
uses make as normal, which is implemented via fallback to
GenericBuildSystem.

Previous to this the GenericBuild fallback of 'Makefile' was used to
test if a configure step had been run, but this only works for CMake
when the default generator is being used.

The 'ninja' generator is available in the latest CMake and seems to be
popular. Instead of hard-coding support for ninja we just try to support
something CMake-specific. Those who wish to use ninja should be able to
use cmake-options to add the appropriate -G flag, and
custom-build-command to specify ninja.

CCMAIL:afiestas@kde.org

A prompt is used to ask if a proxy is required, unless the normal
http_proxy env. variable is set, at which point the proxy URL will be
queried for directly (and the value of http_proxy used as the default).

This should implement wish 305410.

BUG:305410
FIXED-IN:1.16

This adds an option git-desired-protocol to allow for using HTTP instead
of git protocol when updating git modules.

For non kde-projects modules, it should already be possible to use an
http:// URL as a repository instead of git:// (though I haven't tested
this yet).

This should implement wish 305409.

BUG:305409
FIXED-IN:1.16

This audit was just comparing the list of config file options between
the documentation's list of options and the list contained in
kdesrc-build.

This resulted in adding an option (persistent-data-file) to kdesrc-build
to indicate that it's expected, and documenting an option
(use-clean-install) that was present but undocumented.

Right now this will be utilized for anything needing libwww-perl
(kde_projects.xml download, tarball snapshots), and will be propagated
to subprocesses via http_proxy environment variable, unless that
variable is already set.

Tested by using a simple HTTP proxy utilizing HTTP::Proxy from CPAN.

Implements wish 305411.

BUG:305411
FIXED-IN:1.16