This allows for many useful language improvements, especially support
for new package declaration syntax and the use of array/hash operators
on references. 5.14 has been out for a few years now, and AFAIK is now
available in all recent distros.
By moving this code and associated utility methods into Application we
nearly complete the long-in-progress refactoring of the monolithic
kdesrc-build script into proper classes/objects.
The kdesrc-build script itself is nearly bare, but there's still a bit
more to do.
At least it should be easier to make individual test scripts to test
different bugs instead of having a monstrosity of a kdesrc-build-test
script that has to maintain a common state.
I've tested this in each way that I'm able (run needing to make a new
source dir, build dir, new install and log dir, run updating existing
checkouts, bzr/svn/git/kde-projects all tested, etc.). But this was a
large move so let me know if I've missed anything.
This is a long-overdue change that allows for overloading the
stringification operator to produce better error messages.
BuildException was previously not an actual module since kdesrc-build
itself was just a single script file. Now that we allow modules on disk
there is no reason to leave the exception class as a figment of Perl's
imagination.
In the past some KDE SVN modules used the "svn external" feature to pull
in other SVN repositories. These svn-external links were on the *server*
side so the link URL had to use a single scheme.
This scheme was https, which caused quite some problems for anonsvn
users just trying to update from SVN being an unattended kdesrc-build
run, as the SSL cert for svn.kde.org was not signed by a well-known CA.
As a result kdesrc-build updated svn automatically with the expected KDE
SVN SSL signature to avoid blocking on the interactive warning.
This is no longer required. The modules that used svn externals have
pretty much moved onto git now. The new svn server does not even have an
https interface, so this is dead code now, and removed accordingly.
This also required updating the test suite, which rather surprisingly
doesn't seem to need further modification (probably since the test-suite
includes kdesrc-build as a prerequisite, which sets up the @INC
modifications required).
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.
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...
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.
Wanting to get at least some testing done of git-clone functionality
given the large refactor that I have rebased into master, I ended up
adding a simple test to checkout kde-build-metadata. (Testing the
refactored code on existing git checkouts is the easy part for me)
As it turned out, that test caught a different bug (kde-build-metadata
should not use the global branch option).
A couple of git tests were passing when the test suite was run from a
git checkout and failing when not. This was due to an underlying
errorneous assumption.
This commit fixes that assumption by making a new
git checkout, and also changes to the temporary directory setup for the
test at the start to hopefully prevent other tests from passing when
they shouldn't.
BUG:299579
FIXED-IN:1.15.1
log_command supports calling an internal subroutine instead of
exec()'ing a new process in the logged child. The subroutine is
identified by name.
With the move of log_command to ksb::Util, log_command now assumes that
the named function will be found in ksb::Util instead of the main
package, but none of the users of this feature were ported over.
This led to bug 297158 (kdesrc-build fails to --refresh-build a module)
since the 'prune_under_directory' routine used to refresh the build
directory wasn't being called by log_command anymore.
Thanks to Kevin Lyles for the prompt and informative report!
I've added a (very simple) test case to ensure the subroutines can be
called at all (a test which now passes).
BUG:297158
FIXED-IN:1.15
After doing the same for git support the non-modular code base might be almost
tractable.
In addition to the movement of code I also added a testcase for KDE SVN SSL
signature installation.
This allows log_command users to not have to much about with LC_ALL or friends
themselves.
To avoid parameter bloat a hash reference of options to use is now passed as
the final parameter.
The idea is going to be to have the renamed filter_program_output be the one
way kdesrc-build handles reading program output, so that I can move all the
locale-disabling code strewn about the code base to just one function and
hopefully handle everything related to disabling message translation while
passing command line arguments correctly.
As opposed to having Test::More figure it out automagically (which I was only
doing because changing the number of tests expected with a changing test suite
is more work than I really need).
It has always been the intention since module-set was introduced that it
would be possible to override options set for a module used in that
module-set by making a later module declaration, without that later
module declaration actually changing the build order or making any other
effect. This feature was broken and reported as a bug.
I've added a testcase to reproduce the problem, and I have fixed it by
passing back to parse_module() existing Module objects when present, and
modified parse_module() to not create new Module objects in that case
but to modify the one provided.
I've also added a warning for modules that do not appear to be part of a
module set as this indicates duplicate modules passed in the config
file. As of right now the way this test works is to look for a
module-set name but those are optional, so what I'll probably do is
auto-generate a module-set name based on the line number. That will come
later though.
BUG:288611
FIXED-IN:1.15
Although dumber than I thought the bug would be, it at least was easy to
find.
The reason list_has() accepted the prior code was that it seemed to be
getting called with a @curList of 0 entries instead of 1 entry (when
there was no existing environment variable set).
I'm still not entirely sure but I believe that was caused by the bug
fixed by this commit, where the environment variable name would end up
prepended to the value. If there was no value assigned it would just
assign a value with 1 entry, which would have tripped the bug when used
later.
Please let me know if this is fixed, I've tried to add a few more
testcases which all pass at this point.
BUG:291357
This allows single-elements lists to not be guessed as a list reference
in list_has, which helps with bug 291357... but still doesn't explain
why old code that used list_has didn't have the same issue.
I have included a test case which fails and is likely related to the
reason though, so hopefully won't be hard to pin down from here.
CCBUG:291357
Specifically, move to Module::setupEnvironment, which is more
descriptive of what is actually going on.
Now it should be possible to move install-handling code to Module as
well without having to make additionally calls out to the main package.
This is mostly so I can finally make the install/uninstall process a
part of the build system as it needs to be. Right now the BuildSystem
handlers don't have access to the environment variable handlers without
accessing the main:: package directly, and I'm trying to minimize that
in new code.
Pretty much what it says in the subject, although it depends at this
point on auto-detecting the proper build system correctly.
If you want to see what build system kdesrc-build thinks is required,
run with --verbose or --debug, and the build system will be displayed
with the module name during the build phase.
I mistakenly said an earlier commit implemented this feature though,
it's actually *this* commit.
CCBUG:265255
Apparently Perl has included (since version 5.0, no less) a module that
handles almost the exact case split_quoted_on_whitespace exists for.
The impetus for this is that the '${MODULE}' syntax for dest-dir is
apparently broken due to problems with the mixture of braces and quotes
in split_quoted_on_whitespace.
This change does not break the test suite (but does add a relevant test)
and does seem to fix the issue with strings with braces.
CCMAIL:rakuco@FreeBSD.org
In a previous commit I made a "large refactoring" that involved using
mixin classes to decide at runtime what build system or scm handler to
use for a given module.
In retrospect, using what is essentially a static class member to handle
a per-object decision was not my most impressive moment ever... this is
easily fixed by having specific scm() and buildSystem() members for each
Module instance, but does involve yet-more modification of code in lots
of places. :-/
Moving ksb::Phases to ksb::PhaseList gives room in the namespace for a
real ksb::Phase, although at this point my eventual "Phase" will
probably not be a separate class but instead a simple hash or something
in a dependency tree.
The test suite now works again. One test related to the kde-languages
option was removed since I expect that the feature is not ready, but all
other tests still pass.
David Faure
Michael Pyne