frameworks build issues

Kevin Ottens ervin at kde.org
Thu Nov 24 12:21:51 UTC 2011


On Wednesday 23 November 2011 11:44:50 Stephen Kelly wrote:
> Stephen Kelly wrote:
> > David Faure wrote:
> >> On Tuesday 22 November 2011 15:29:25 Stephen Kelly wrote:
> >>> We can enforce this by creating a 'done' folder, and calling
> >>> add_subdirectory(done) in kdelibs.git/CMakeLists.txt as early as
> >>> possible. At least before the call to find_package(KDE4Internal
> >>> REQUIRED).
> >> 
> >> Moving stuff means adjusting 100 includepaths yet again...
> >> 
> >> How about doing what you suggested in tier1 and then moving it up in
> >> kdelibs.git/CMakeLists.txt?
> > 
> > Yes, that would work.
> > 
> > I'll do that if I can just comment out any subdirectory that doesn't
> > build.
> 
> I did have to move kcoreaddons and karchive back to the kdecore directory.
> Those three are interdependent still, so there's some more work  to do
> before they can be split out.

I'm slightly concerned about the message it sends to contributors now. It's 
kind of one step forward, one step back. Also, if you work within kdecore for 
instance it makes it harder to catch the real problems (we spotted some only 
when moving out), so why bother moving if you know there's one dependency you 
can't cut yet? (like KSaveFile for libkarchive).

Of course, I agree and understand the technical issues behind it, I'm just 
concerned about the social implications. My proposal follows.

> The tier1 directory is near the top now though, so people would have to move
> those back in there and then consider why they don't build and what needs
> to be done about it (using the spreadsheet for reference).

What about moving all the tier* folders near the top as you proposed 
previously and did for tier1, and anything in there which isn't ready goes 
into a "staging" folder?

It would avoid giving the bad message I mentionned above, and give the extra 
level of visibility we obviously miss at the moment. Moreover, we right now 
tend to move stuff directly to one of the tiers based on assumption not 
knowing for sure the final tier it'll reaching, so this staging area would 
help make that explicit.

Sounds to me like the best compromise possible to avoid stalling the 
development, and making sure things get to the right level of quality and 
dependency split before being stamped done.

To sum up the process would be:
kde(ui|core|whatever) -> libfoo in staging -> libfoo in tierX -> split repo 
(when we decide to split, so not yet)

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20111124/0a0ad3c3/attachment.sig>


More information about the Kde-frameworks-devel mailing list