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
My previous patches required you to pass 'l10n' on the command line, now
kdesrc-build will add the required module to the build automatically if
the kde-languages option is in use (at the end of the build).
This should complete making the kde-languages option work, but more
testing is always good! ;)
BUG:283027
We remove the pretend line to allow for more of the run to be
'pretended' (log_command still won't run a command in pretend mode)
Also I use the recently-introduced languages() helper.
This gets it far enough into the install subroutine to get
installInternal called. The issue is just that the language module
itself is a grouping of languages to build, each of which is really its
own module.
So the default file the install procedure looks for to tell if the build
system was setup won't work, as it's one level too high. (e.g. it looks
for $builddir/Makefile instead of $builddir/$lang/Makefile).
With this change it's possible we'd try to install a language that
didn't actually build at this point, but that's better than not trying
at all.
This is as opposed to safe_make magically knowing to use 'checkout-only',
especially since with l10n it /shouldn't/ use checkout-only.
In fact I think safe_make should be changed to avoid magic detection of
subdirs-or-no-subdirs but that will have to follow later.
Right now that just means the functionality is split between
Module::install and GenericBuildSystem::installInternal but it's now at
least possible in theory for e.g. the qmake build system to add the
required DESTDIR= parameter to install to the right location.
This has built for me just fine on a couple of modules so far, haven't
been able to compile further though.
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 gets rid of setup_module_environment (which moves set-env options
into the actual queued environment for the child handling
update/build/etc.), now just need to port update_module_environment.
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.
Really this is just an excuse to build krapyl... although I needed to
add LIBS += -lqca, and there's no install capability either here or in
krapyl.
But it only took 45 lines and the logic is reasonably straightforward
for once... maybe this refactoring has turned overall useful by now. :)
By the way for those wondering...
# eV vote verifier
# Don't bother with cmake-options or configure-flags...
module krapyl
repository kde:scratch/sune/krapyl.git
end module
CCMAIL:Sune@vuorela.dk
This makes l10n languages fall under a single l10n module (auto-added as
necessary) which is tied to the l10nSystem (both a build system and scm
object).
This should at least lead to updating right, although I still need to
make the build and install processes work correctly.
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
Instead of looking at qt-copy, look for any Qt build system (which has
the large modules) coming from gitorious.org (which has the problems
with the large modules).
Now as long as the build system is 'QtBuildSystem' we will ignore
Qt-specific options.
One problem is that the order of evaluation *had* to be reversed by
doing this, the way I have it coded now ends up with some kind of
5-level mutual recursion since the build system check will try to lookup
what directory to use if it's not already configured, and that
necessarily involves getOption calls.
Reversing the order of evaluation allows us to defer this check until
after it's actually necessary (by which point no special lookup should
be needed to figure out the build system type) but there's probably a
better way to do this...
This extends the current ksb::Debug::debugging call such that you can
pass in a debug level to be compared instead of just assuming the most
verbose level.
There is already a framework-phonon module-set with the right entry for
phonon (phonon/phonon instead of phonon, which will build all
phonon-related modules).
Log said "make: *** No rule to make target `Experimental'. Stop."
Script said:
Use of uninitialized value $numTests in numeric gt (>) at /d/kde/inst/kde4.8/bin/kdesrc-build line 2420, <$logf> line 2.
Now it says:
Some tests failed for konsole, consult [...]/log/2011-12-27-06/konsole/test-results.log for info
If we create the full source path the rest of the script will get
confused and think there's existing source there already (since I've
been too lazy to code a check if the source dir is empty or not).
Although I don't think this was the exact cause of the
kde-build-metadata problems (but instead the moved SCM type setting),
this does at least have the effect of moving an update under the 'Script
started processing' message, which is probably where it should be.
Having the proper SCM type ensures that the &filter subroutine in
expandXMLModules actually sets the repository value for our
kde-build-metadata module.
Michael Pyne
David Faure
Raphael Kubo da Costa
Eike Hein