kdesrc-build only used the "branch" option for git modules when updating
existing git clones, not when actually cloning a module. Now it tries to
check out the appropriate branch immediately after cloning the module.
Thanks to kgw for reporting the bug. The fix should be in the eventual
1.14 release (or you can simply download the kdesrc-build script from
git)
BUG:268202
FIXED-IN:1.14
I already had a sub clone_module method which wasn't as accurate as
dclone, and I'm already using Storable anyways so might as well take
advantage of the code size reduction.
... when using the recommended setup
http://community.kde.org/Sysadmin/GitFAQ#Let_Git_rewrite_URL_prefixes
Otherwise kdesrc-build would do
git remote add __kdesvn-build-remote git://anongit.kde.org/kdepim
just because it can't match kde:kdepim with git://anongit.kde.org/kdepim
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.
Montel Laurent
Michael Pyne
Matthias Fuchs
Anne-Marie Mahfouf
David Faure
Pino Toscano