Sorry about changing dependencies, but LWP seems to be the standard Perl
solution for downloading files, so it's likely to be more prevalent
anyways. Neither group of dependencies appears to be part of core Perl
so I'm having to pick either way.
Picking this way allows for a large reduction in code usage while still
properly handling redirects.
Sometimes I really miss static typing. This is the kind of issue that is
supposed to be caught by unit tests in dynamic languages, but the test
suite isn't close to that extensive yet.
This fixes bug 268072 (kdesrc-build without modules passed in fails).
There is a test case which simulates kdesrc-build without modules passed
in, but it doesn't simulate the entire sequence and so didn't catch this
error. My apologies.
BUG:268072
Following on with the last commit, if an exception is thrown while
parsing XML modules, the database is re-downloaded once, which should
hopefully automatically fix things if the XML gets corrupted.
This is particularly annoying with the proj.k.o support, as a
half-downloaded XML file is 100% invalid, and will cause XML::Parser to
throw an exception.
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.
So what I've done so far is to introduce a "BuildContext" class, since
it doesn't make sense for a simple Module class to also track the global
module list. This also makes the phase handling (also split out to a
different list to avoid code duplication) a little more normal.
Now the only global state in Module is related to the source of where
modules to be built was established (config or cmdline), which probably
needs to be moved as well.
In the long term much more will be modularized (even though I'll
probably continue to leave it all within one file).
I try to keep kdesrc-build as a single integrated script for ease of
use, so it is extremely long by this point. I do need to go through it
and clean up, but I've read about a way to have vim automatically create
folds based on markers added to the source, which makes navigating the
file much easier.
By using POSIX::nice (since POSIX is already in use anyways) I don't
have to declare a random PRIO_PROCESS constant to use the Perl
setpriority built-in.
I'd like to switch the kdegraphics example fully over to
projects.kde.org's database, but the kdegraphics supermodule is not
constructed at all yet (I can't even find any git submodules) so
until then just spell out each needed submodule.
The logic for build system setup is essentially: There is CMake, or
qt-copy.
Obviously there are other types of modules (including the empty
mobipocket repository...) so be more specific with the error message in
that case.
kdesrc-build prefers module names fed in from the command line
(obviously ;), but if the module didn't already exist on disk then the
only source of info about the module is probably encoded in the rc file,
but the modules read from the rc file were ignored.
This change simply copies over the more accurate rc-file-based modules
that have matching names, without this change you'd get modules that
tried to git-clone themselves from "kde-projects" instead of
git://anongit.kde.org/foo.git since the pass the alters repository
settings only runs on modules that are supposed to be based off of
projects.kde.org.
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.
In Perl, packages are used essentially for namespacing, which means that
notations like Package::foo() make sense (call function foo from
Package).
On the other hand, Package->foo() /also/ means something (call
Package::foo(), but pass class name as first parameter, then rest of
parameters).
To forestall my confusion later, just unilaterally make Module->foo the
only working option (since the -> notation is required for many uses
anwyays).
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.
I left this out somewhere along the line, so users of kdesrc-build
master haven't actually been downloading updated databases for a couple
of weeks now. Oddly, I seem to be the first one to have noticed...
The exceptions we throw need to be obtained via make_exception otherwise
a horrible-looking Perl error gets developed and I don't feel like
Googling again which exact permutation of "blessed" or "ref" or what
must be used to get what I want.
In addition this is one of the very few commands which might be run in
--pretend mode, and the only one that is not strictly read-only. However
we need some form of information regarding kde_projects.xml if the
method in question is being called at all so I choose to hit the network
instead of having no information in the --pretend output.
Subversion modules had tracked the last-built and last-installed
revisions in order to make some other minor features work. We save that
information for git modules as well now.
Switch to a more modularized concept of phases led to another bug,
automatically switching svn repositories if the user passed --src-only
no longer worked since a required flag was no longer set.
So, we set a flag again, but this time it's actually very specific as to
its purpose.
I guess mjansen found a way to get svn_module_url to return a path
ending in a slash (probably override-url, I was able to reproduce that
way), which can bring up an annoying warning about a harmless condition
if the svn repo itself doesn't end in a slash.
So, simply remove trailing slashes from actual svn URL and expected svn
URL before performing the check.
BUG:266233
It actually still exists (although called DebugFull) but it's probably
better to use the optimized-but-debuggable "Debug" profile as a generic
example, especially since stock CMake is aware of Debug.
Reported by "guy-kde", thanks for the report!
CCMAIL:guy-kde@maurel.de
Nowadays Phonon does not come with any backends built in, so we need to
specify what backend to use.
The two best choices are phonon-vlc and phonon-gstreamer. I've chosen
phonon-gstreamer for the default merely because that's the one that
works on my system.
Thanks to Ghislain MARY for bringing it to my attention.
BUG:263937
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).
Setting global options for no-src, no-build, etc. is no longer required
in kdesrc-build since the process_arguments() routine will clear out
that particular phase for all modules, and in fact ends up interfering
with a check for whether those options are set in the rc file.
First noticed by Kurt Hindenburg IIRC, but I can't find the email now.
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.
Now the act of actually finding the rc file to use is separate from the
act of reading it.
Again, this is mostly to actually make testing easier, although it will
make it very easy to add in a "real" built-in default config file
instead of the current programmatic hacks I have going on now.