Questions on module splitting

[Kevin Ottens]

Hello,

On Tuesday 27 August 2013 19:03:56 Aleix Pol wrote:
> I've started looking into splitting KUnitConversion, there's some things
> I'd like to discuss:
> 
> - There's some weird constructions
> regarding KDE_PLATFORM_FEATURE_BINARY_COMPATIBLE_FEATURE_REDUCTION.

This came from the KDE Platform Mobile time. This can go away.

> Especially a trade off between depending on QtNetwork or using kioclient to
> download a specific file (see currency.cpp). I'd suggest to have only one
> code path, and I'd say using QtNetwork can be the best, especially since
> the dependency on kio is at runtime.

Yep, AFAICT QtNetwork is enough for KUnitConversion.

> - Currently there's a directory called kunitconversion/src/kunitconversion
> that contains all the files. To me it would make more sense to have
> everything within kunitconversion/src. I would have changed it if it wasn't
> because there's also Solid with solid/src/solid, and it's marked as Done.
> Anybody has any insight about this?

Right, it's not nice, it was me doing it quick and dirty at the time when we 
needed to start moving KUnitConversion for dependency reasons. The right way 
to do it would indeed to have the lot in src, and generate local forwarding 
headers, like David did in sonnet.

> It doesn't seem to follow [1].

This policy doesn't say this construct is forbidden. :-)
 
> - About i18n calls, it says something like we shouldn't be using i18n()
> when depending on Ki18n. What should we use then? i18nc()?

Not sure I understood here...

BTW, what are the dependencies for KUnitConversion currently? I wonder if we 
want to make it a low tier if we can.

> - Also it talks about:
> Document all dependencies in CMakeList between frameworks (example in kauth)
>
> I've looked into KAuth and I don't see what's different from other
> submodules. Does it mean that target_link_libraries() calls are well made?
> find_package()?

I used to have the following lines in kauth:
include_directories(
     ${kcoreaddons_SOURCE_DIR}/src/jobs # for KJob
     ${kcoreaddons_BINARY_DIR}/src
)

Since we don't use include_directories anymore for this kind of cases it 
disappeared. We should do that on target_link_libraries calls now but 
unfortunately it hasn't been done in KAuth (should be ASAP).

The idea would be to make its target_link_libraries call the following:
target_link_libraries(KAuth
    LINK_PUBLIC
        Qt5::Core
        KCoreAddons # for KJob
    LINK_PRIVATE
        Qt5::Widgets
        Qt5::DBus
)

The idea is to have something like that in all tier 2 and tier 3 framework so 
that it's easier to figure out if we can get a framework down a level of what 
justifies a dependency.
       
Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter 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/20130828/3ddf8e4e/attachment.sig>