On Friday 01 November 2013 13:37:56 Kevin Ottens wrote: > On Friday 01 November 2013 12:53:17 Alexander Neundorf wrote: > > On Friday 01 November 2013, Kevin Ottens wrote: > > > Hello, > > > > > > On Friday 01 November 2013 11:23:14 Mirko Boehm wrote: > > > > On 11/01/2013 10:46 AM, Alexander Neundorf wrote: > > > > > [1] Why not merge that into CMake ? For quicker releases, and even > > > > > easier contributing. Also Bill once said that in hindsight he would > > > > > have prefered if cmake would not ship any find-modules itself at > > > > > all. > > > > > So one could imagine that cmake would come without any find-modules > > > > > in > > > > > the future, and all find-modules would come from a separate package, > > > > > e.g. ECM. This would make cmake the core tool, and ECM its "standard > > > > > library" > > > > > > > > I agree that a separation of CMake and the find_modules make sense. > > > > But. > > > > > > My position indeed. I would agree at a "tier 0" if it didn't make it > > > miserable for third parties wanting to use a tier 1 library in the sense > > > of "oh by the way you also need that, and that, and that thing no one > > > else > > > use". > > > > if a package foo uses ecm (or that non existing tier0 cmake package) > > itself, this does not mean that another package which uses foo, also > > needs ecm (or that tier0 package) at buildtime. > > Well, if the tier 0 package contains the compiler settings for our > frameworks, it'd mean everything tier 1 and up would use it. The > alternatives right now being: duplicate the info or have it in cmake/ecm.
Although overall I like the feature Mirko is proposing. I figured out something regarding that statement of mine just above... For the specific case at hand, assuming we'd have a tier 0[*] and we don't want third parties to bother about it either while cloning the repo or while getting a tarball... Might be a stupid idea but... isn't it something we could inject using git submodules? It looks like a proper tool for the task. Opinions on that? Cheers. [*] I'm not against that idea per se (never been), I see the value in it. But if we go for it I want to make sure it's transparent for third parties. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
