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.
Fixing the test suite for my recent refactorings ended up being quite
the trip through the looking glass.
I ended up making the run-test phase not enabled by default due to
always filtering it out in the test suite. So naturally I just add it
back in if we're using the run-tests option. But naturally *that* change
warrants test suite coverage, and testing it out gave me error about
finding main::list_has, since list_has is really test::list_has when the
test suite is being run.
Using Perl's caller function allows me to reset the package to main at
the start of kdesrc-build and still detect when it's being activated as
part of the test suite, but then the functions in the test suite don't
work until I switch *its* package to match.
It all does seem to work now though.
The logging subsystem test case was passing because of an old log
directory I still had on my system. I've fixed the test case to use the
existing temporary test directory and to not use any existing log
directories.
I've gone over the code one more time, this should hopefully be the last
reference to anything on my system. :-/
The test suite comments hint around the fact that an exception should be
thrown if --resume-from and --resume-after are both set, it's not
actually that hard to verify an exception is raised, so go ahead and add
a simple test for that.
Pino Toscano noted that there were several tests failing on his system
after (well, and before ;) he changed the source directory setting in
the test suite to be under the home directory.
Indeed he is right, although I removed references to my home directory
when uploading my test suite, I did not remove references to my source
and build directories, which naturally did not contain svn sources on
Pino's system, which caused several tests to fail.
Now the testsuite will do a svn checkout (of kdesupport at this point as
I feel it is most likely to hang out in svn) before running tests on
functions requiring a svn source directory. The checkout is constrained
to avoid checking out any files or referencing any external svn
checkouts and is only run when running the test suite, so hopefully this
doesn't represent any significant load on the KDE svn servers.
In addition the base directory for all operations is under a temporary
directory, cleaned up when the test suite completes. Right now the
temporary directory is created under the normal temp dir (/tmp on my
system), the Temp::File docs seem to indicate this can be changed by
specifying DIR => /path/to/dir when running tempdir() if desired.
Finally, I ended up adding a test for the directory creation function in
the process of testing the test suite, which I left it because it's a
good idea anyways.
All tests pass on my system now with these changes, hopefully that will
be the case elsewhere.
1) updateModulePhases is supposed to act mostly like a
functional-language type of function, where it returns a filtered list
based on the input list. However, since every element in the list is a
reference to an object, doing a copy-then-modify still means you're
working on the original object. For now I solve it just be cloning the
entire input list, but I'll probably want to add a real copy-ctor or
clone method in the future. Not many functions handle Module objects yet
so this seems to be the only case requiring a change. This was found
when trying to add a test case for:
2) Ensure that using --no-src at the command line doesn't also clear out
the build/install phases (as is supposed to happen when e.g.
manual-update is specified in the rc file).
kdesrc-build-test.pl has always given me a warning about redefining
some note subroutine. Turns out Test::More includes a subroutine called
note, but we don't need it, so exclude it.
Michael Pyne