On Tue, March 3, 2015 08:29:16 Marko Käning wrote:
> > With that said, kdesrc-build *will* ignore modules that have a defined
> > branch of "" (i.e. empty) in logical-module-structure, so if a module
> > simply should not be built for a given branch-group my recommendation
> > would be to define the branch-group after all but set it to an empty
> > value. E.g.
> >
> > "kde/kdenetwork/ktp*": {
> >
> > "stable-qt4": "kde-telepathy-0.9",
> > "latest-qt4": "kde-telepathy-0.9",
> > "kf5-qt5": "master",
> > "stable-kf5-qt5": ""
> >
> > },
> >
> > I believe that Scarlett's new CI supports this as well, and the current
> > Jenkins CI also supports this.
>
> Scarlett’s CI also supports to treat *undefined* entries as _set to empty_,
> just like my OSX/CI does.
>
> So, in the light of your remarks the question is, whether all the
> removed empty definitions in my RR [1] should actually be left the
> way they are!?!?
Hi Marko,
There's a reason I'd mentioned kdesrc-build's current behavior in my reply to
that RR. :)
I personally would retain empty entries. But kdesrc-build can and should
change to adapt to what's best for KDE development. As I mentioned in the RR,
if we're now at a state where every module that should be recorded in kde-
build-metadata *is* recorded in kde-build-metadata (so that a user can build
any KDE git repository using kdesrc-build) then I would certainly be willing
to change the behavior of kdesrc-build to reflect the CI.
But that would be a significant behavior change, especially for lesser-used
modules (e.g. in playground/) that don't necessarily receive CI coverage, but
which users and developers may still want to build via kdesrc-build. It would
still be possible to build such modules without kde-build-metadata defined for
them, but users would have to manually add the module using something like
module playground-foo
repository kde:kfancyfoomodule
end module
I think the real solution (so that we don't need empty branch-group hacks)
would come from finally implementing the proposal Ben and I had made back in
August 2014 (currently just an email thread in kde-frameworks-devel
https://mail.kde.org/pipermail/kde-frameworks-devel/2014-August/018391.html).
I ran out of time to do effectively any development for some months after
that, so as far as I know there's been no progress. But that's the direction
we *intend* to head... now would be a good time if you want to review the
proposal to see if it would help or hurt your efforts.
Regards,
- Michael Pyne
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
