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.
i.e. was the module list given on the command line directly, or allowed
to be generated from the config file. It's only coarse-grained (e.g.
filtering options on the command line still count as modules coming from
the config file).
This will be used for properly handling the order for module uninstalls
and possibly for restoring old behavior on module installation with
--install.
Now fix the manual install phase (i.e. when you specify --install on the
command line).
One behavior change is that kdesrc-build used to install only modules
that were successfully built if you ran only "kdesrc-build --install",
now it will try to install modules that it would normally try to update
and build, and since "make install" command normally implies a build
this can make the install process take a bit longer since you're still
doing a build anyways.
If this is actually an issue to anybody just let me know and I'll adjust
to get closer to the old behavior.
get_build_list used to be used to not only "get the build list", but
also filter out modules to build based on --resume-from and
--resume-after. kdesrc-build now generates a list of Module objects
which was not tied into get_build_list, but now the old behavior is
back (and improved, --resume-foo doesn't force --no-src anymore).
As noticed by dfaure. It turns out that I was simply lazy and didn't
want to use the same logic in both get_update_list and get_build_list,
but those functions are effectively useless now anyways with the new way
of figuring out modules to work on (although there's still a few
bugfixes needed for that new code).
It used to be that unknown modules would simply be attempted to build
anyways, and it would be amusing if it failed, but with the new method
of handling regular and XML-based modules, an unknown module simply
causes no output and a successful return message.
Now it results in an exception being thrown.
Basically, nothing good can come of more auto-guessing of this style.
dfaure has encountered issues with it, and I've run into a few yourself.
Just specify the right repository (and you should be using module-sets
by now anyways) and we'll all be OK. ;)
Having use-modules and use-xml-modules is stupid.
Instead, you can use "kde-projects" for the existing repository option
to allow kdesrc-build to know that you mean for the module to be built
based on the KDE Projects structure, and kdesrc-build will handle the
rest, and then use use-modules as normal.
This means that you can't mix XML-based modules and the old-style
modules in the same module-set, but oh well...
You can still use +-prefixed module identifiers on the command line as
well.
set-env requires using the internal handle_set_env to get setup
properly. Actually use it.
In addition, actually copy module-set options over to xml-based modules
as well.
By naming module-sets, it becomes possible (with some more work in this
commit) to quickly build given module-sets from the command line,
instead of having to still laboriously give labels to every module
contained within the set.
Michael Pyne
Montel Laurent
David Faure