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.
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).
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.
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
Brought up by me noticing use-modules was way out, though it apparently
wasn't the only one. Done by selecting the lines, then running through
"sort -i".
The failure to do so at this point means that git-clone will not use the
tarball snapshot even though it's available, which is not going to help
KDE git infrastructure at all.
BUG:305408
FIXED-IN:1.16
This is in preparation for making that package/module re-entrant and,
more importantly, for being able to add support for alternative
protocols (other than git) without having to pass a ton of parameters to
the current method.
We don't need dont_build now as it's used in just two places and it is
easier from a flowpath perspective just to have the applicable bits
inline. It could possibly be refactored properly later but it works now.
There was a bug with printing to STATUS_FILE that wasn't guarded by
checking to see if $outfile was defined, which was causing errors when
printing that a module failed to update/build in --pretend mode.
I could have fixed it by adding that check but it's probably better to
have it always valid.
We can't set $outfile to '/dev/null' unconditionally since we decide
whether to create log/latest symlinks based on whether $outfile is set
or not. So instead I use a defined-or (//) operator in the open call.
Subversion 1.7 requires a manual upgrade of the working copy in order to
do anything (even to run svn status). Luckily there's an error message
ID for this case so it's not too hard to grep for situations where this
is necessary.
One problematic element is that since even 'svn info' doesn't work in
this situation, --pretend mode doesn't work either for svn modules. For
now I just throw an exception (after the check) when in pretend mode so
avoid follow-on useless error messages.
It was interesting how I still had the old 1.6.17 for so long -- turns
out I had forgot to rename my subversion selector asking for unstable
versions in Gentoo (at some point their package name changed from
dev-util/subversion to dev-vcs/subversion, which I didn't keep up with).
Thanks Will Stephenson for the bug report.
BUG:304415
Unfortunately I was not able to split out moving safe_make and
run_make_command with the actual implementation of this option
after-the-fact. Whoops.
This should implement support for a custom build command (and custom
install command, assuming the install can be performed by adding
'install' to the command line).
Hopefully that will be sufficient for 'ninja' or other buildsystems.
Note that this only changes the *build* command, the other parts of the
build system still needs to be supported in kdesrc-build (for now,
custom build systems probably wouldn't be too hard to implement if
necessary).
Assuming your proposed command is available in PATH and can be called
like make, doing something like this should suffice:
module (or module-set) foo
custom-build-command ninja
end module (or module-set)
BUG:303692
Michael Pyne
T.C. Hollingsworth
Script Kiddy
David Faure