This commit activates the recently-added DependencyResolver to try and
ensure the desired build occurs in the proper order.
Surprisingly, there's no open bug about this.
Instead we note that a required module is not in the current build, but
that could certainly be OK... at this point I don't want to auto-add the
missing module but that could certainly be a command line option or
something.
This is as already defined in the initial spec for dependency resolver
metadata, just didn't always follow through in the implementation (this
also works around a misfeature of the current impl).
Now you can type in random module names and as long as they're somewhere
in kde_projects.xml, kdesrc-build should even Do the Right Thing(TM). It
even still gives the same kind of error if it turns out the module
/wasn't/ a KDE Project...
CCMAIL:faure@kde.org
Must of my problem tracking down the last commit was with what I thought
was another bug in the list_has util method.
Investigating that has led me to the conclusion that prototype usage
here is just a bad idea, so I'm picking a calling convention that's
mostly like to cause a runtime error if violated (i.e. passing the list
as a reference) and will be using it consistently.
The ignore list can be checked by ctx->addModule() even in code paths
where it is not set first by KDEProjectMetadataUpdate, it should be
initialized to be an empty list instead of undef.
This actually had some test suite coverage, except that the test suite
was expanding our the modules in the kde-projects module set manually
before running applyModuleFilters.
Something to add to the test suite later I suppose...
BUG:290450
It has always been the intention since module-set was introduced that it
would be possible to override options set for a module used in that
module-set by making a later module declaration, without that later
module declaration actually changing the build order or making any other
effect. This feature was broken and reported as a bug.
I've added a testcase to reproduce the problem, and I have fixed it by
passing back to parse_module() existing Module objects when present, and
modified parse_module() to not create new Module objects in that case
but to modify the one provided.
I've also added a warning for modules that do not appear to be part of a
module set as this indicates duplicate modules passed in the config
file. As of right now the way this test works is to look for a
module-set name but those are optional, so what I'll probably do is
auto-generate a module-set name based on the line number. That will come
later though.
BUG:288611
FIXED-IN:1.15
Although dumber than I thought the bug would be, it at least was easy to
find.
The reason list_has() accepted the prior code was that it seemed to be
getting called with a @curList of 0 entries instead of 1 entry (when
there was no existing environment variable set).
I'm still not entirely sure but I believe that was caused by the bug
fixed by this commit, where the environment variable name would end up
prepended to the value. If there was no value assigned it would just
assign a value with 1 entry, which would have tripped the bug when used
later.
Please let me know if this is fixed, I've tried to add a few more
testcases which all pass at this point.
BUG:291357
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.
Michael Pyne
David Faure