frameworks build issues

[Jeremy Whiting]

On Tue, Nov 22, 2011 at 7:29 AM, Stephen Kelly <steveire at gmail.com> wrote:
> Jeremy Whiting wrote:
>
>> Hello all,
>>
>> I took another crack at the kcolorscheme migration in frameworks
>> branch yesterday, and got it to not depend on KGlobalSettings any
>> longer.  Unfortunately I still get warnings when I run cmake like
>> this:
>
> There are two issues.
>
> For one of them I filed a bug against cmake:
>
> http://public.kitware.com/Bug/view.php?id=12588
>
> The second issue is that libkgui depends on kdecore, which is not a
> 'framework'. It's premature for libkgui to exist if it depends on kdecore.
> The things that it depends on in kdecore would have to be split out.

Oh, I see.  I was just storting with code I knew rather than working
from the bottom up.

>
>> Should we be using separate branches to work on stuff like this and
>> merge them into frameworks when they build?
>
> I think that would just complicate things. I think what we actually need is
> more structured efforts. The people who want libkgui to exist need to do
> work on the lower levels before creating it. The things libkgui depends on
> need to be close to their final state (in terms of build and dependencies)
> before libkgui can exist. This is where we need concrete goals which will
> hopefully be hammered out in the IRC meeting.
>
> The most important thing we need right now is modularity, which we can do
> better to enforce in the buildsystem. It should be possible to build things
> standalone. Currently for example solid and kcoreaddons can not be built
> standalone because they get config.h from the top level 'kdelibs', along
> with their dependencies, and they use cmake macros that they should not
> (macro_bool_to_01() is replaced by #cmakedefine01 for example), so
> libkcoreaddons is not 'done' or 'ready', however you want to call it.
>
> To be 'done' it would need to create its own config file with the stuff that
> it needs, find its dependencies by using Find packages from extra-cmake-
> modules, port away from the no-longer-used cmake macros such as
> macro_bool_to_01 and macro_optional_find_package. This is what 'done' looks
> like and is what we need to aim for for each framework.
>
> 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).
>
> This will mean that kdelibs.git/cmake/modules will not be used anymore etc,
> and mean that for a framework to work in the 'done' folder, its cmake stuff
> needs to come from extra-cmake-modules.
>
> I can create that folder soon and start moving things in there (at least
> itemmodels is 'done' already).
>
> Any objections?

Makes sense to me, mut I am a bit new to frameworks work too.

Jeremy

>
> Thanks,
>
> Steve.
>
>
>
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>