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, [email protected], http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
