On Wed, Mar 4, 2015 at 2:00 PM, Michael Pyne <mp...@kde.org> wrote: > 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.
I concur that the real fix at this point is to update the file format to the new iteration we developed last year and get that rolled out. > > Regards, > - Michael Pyne Cheers, Ben > _______________________________________________ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel