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