KDE-buildsystem-basics package ?

[Kevin Ottens]

On Saturday 21 January 2012 11:46:54 David Faure wrote:
> 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".

Although I wouldn't like something as strict as "let's do option 3, period", I 
quite like your approach to that problem:
 * apply option 3 by default;
 * and if it really needs to be usable by the frameworks let's move them to 
ECM.

Indeed if that's needed by quite a few frameworks it's likely something 
desirable for CMake users outside of KDE Frameworks too. And in most cases 
that would likely solve the consistency issue between the frameworks that 
Stephen pointed out regarding option 3.

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/20120121/0f70fb33/attachment.sig>