KDE-buildsystem-basics package ?

David Faure faure at kde.org
Sat Jan 21 10:46:54 UTC 2012


On Saturday 21 January 2012 00:05:28 Stephen Kelly wrote:
> Options as I see them are:
> 
> 1) ECM provides them. 
> Advantages:
> * KF5 Frameworks can mostly (entirely?) be expected to depend on ecm anyway
> * It provides the single dependency point
> * To some extent the stuff (sensible compiler flags, Qt flags) is also 
> independent of KDE, but KDE has determined them to be a good thing.
> * 3rd parties can still use ECM without using the KDE stuff.
> Disadvantages:
> * It would mean ecm contains 'KDE stuff' which may be icky or unwanted.
> 
> 2) Provide them in a separate package and make all frameworks depend on them
> Advantages:
> * ECM is KDE-free.
> * Package would have KDE in the name
> Disadvantages:
> * It would be odd for all frameworks to have to depend on two 'build system 
> enhancement' packages.
> ** 3rd parties wishing to use a single KDE framework would need both.
> * Back to the situation of a single point of dependency convergence
> ** Temptation to put more 'global stuff' in there (dumping ground) would be 
> high.
> 
> 3) Put them in an 'umbrella' package on top of KF5
> Advantages:
> * Such an umbrella package will likely have to exist anyway to maintain the 
> 'consistency' for application developers moving from KDE4 to 'KDE5'. * KDE
> frameworks are easier to use for non-KDE developers (fewer
> dependencies, using 'standard' add_executable instead of 'alien' 
> kde4_add_executable).
> Disadvantages:
> * The frameworks themselves can't use the KDE buildsystem convenience stuff.
> * The frameworks might end up inconsistent with each other for example in
> what variables they choose to do the RPATH handling.

I agree that these are the available options.
Out of them, number 2 is the worst IMHO (its advantages are just naming, its 
disadvantages are real and annoying).

Number 3 is the ideal solution, I think we should aim for that, and for the 
things where we realize that we really need them usable by the frameworks 
themselves, then use number 1 (move these things to ECM).
I think this will lead to a cleaner solution than "put everything into ECM 
upfront".

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5



More information about the Kde-frameworks-devel mailing list