After my internet went down last night I noticed that the error message
I had the next day didn't show up right (apparently the HTTP::Response
doesn't stringify like I thought.
Trying to confirm that was fixed led me to realize the way I handle
downloading the XML is overly complicated in the first place. Now we
only ever try to download the file once, and if that fails we delete the
result so we can't use it (much like make on failed object file builds).
The other thing we do in case an XML file that is corrupt is present on
disk is to always try downloading the XML file over the existing one on
non-pretend builds, which should hopefully ensure it's fixed over time.
This also permits downloading the kde_projects.xml file when we say we
are ACTUALLY DOWNLOADING etc. when using pretend mode with no xml file
at all present.
kdesrc-build tries to avoid prepending paths to environment variables if
they were already present, but I wasn't checking environment variables
that were "queued" to be applied later, which was preventing this from
working reliably, something I noticed while trying to continue
modularizing update_module_environment.
This is required to be able to use the stringify overload for modules,
and matches how list_has previously worked (when everything was a
string in kdesrc-build).
(cherry picked from commit a9480efc53)
Commit fd54eaf made the module's type undefined to be filled in
on-demand, but there was code manually referring to the type member
instead of going through the accessor. Fixed, except for one case where
the member is being set instead of read.
In keeping with my goal of better modularization, remove the global
@update_list, in favor of the global context object which should be
passed to methods that need that information.
Many places still just generate the appropriate update list manually
that probably don't need to, but that's fine for now.
The long-term goal is for module *objects* to be used in most places
instead of just passing the module name around, but that will come
gradually.
This does mean removing the Coverity plugin support (I left in the code
that tries to do less if Coverity is running), but I do not believe
Coverity is using kdesrc-build to build KDE at this point. If this is
not the case let me know and I'll see what I can do to maintain or
update compatibility for that.
I've received a few comments by now that developers expect kdesrc-build
to automatically reposition the 'origin' remote as appropriate for
whatever the repository setting in the rc file is. I had avoided that
based on not touching things that the developer controls, but it seems
that developers expect the opposite in general, so I'm happy to do that
too.
There's no such thing as kdegraphics super repository. One needs to build it all separately!
This patch gets all kdegraphics apps in the correct order (thanks to bcooskley)
I even found a way to get subroutine prototypes to be exported into
addition to the subroutines themselves, although that requires wrapping
the import() call in a BEGIN { } block if it is important that
prototypes are available when parsing.
I actually did some testing of my last attempt at this, but I'm not sure
in retrospect how kdesrc-build even got something coherent from my first
patch given that I forgot to actually assign the output of the various
read line functions to $_ (which had previously been automatically
done), or how I passed the wrong object type to read_line (now
readLogicalLine).
I've increased the testing performed on the patch and it should actually
work this time. For serious.
BUG:223331
This reverts commit 594f40b413.
Although it works for me, I've received reports that it doesn't for
others so until I figure it out I'll simply revert and work on it when I
get a chance.
CCBUG:223331
Based on a recommendation from Michael Hansen, this commit adds the
ability to include other files from the rc file used for kdesrc-build.
Tilde-expansion is supported on the filename, but only of the ~/foo
variety (not ~user/foo).
It works by essentially intercepting the input stream as necessary, so
unfortunately things like a common "global" followed by different
"global" sections doesn't work (although let me know if that's needed,
it wouldn't be too hard).
On the other hand each rc-file would be able to include the global
options that are common.
To use, simply use "include /path/to/file-to-include" as a single line
in your config file. Leading spaces are supported, but the remainder of
the file after the "include" and all whitespace immediately following
"include" is assumed to be the filename, so don't leave trailing spaces.
BUG:223331
FIXED-IN:1.14
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
David Faure
Raphael Kubo da Costa
Pino Toscano
Michael Pyne
Script Kiddy
Raphael Kubo da Costa
Anne-Marie Mahfouf
Montel Laurent
Matthias Fuchs