Having a Tier 0 for cmake and git submodules

[Alexander Neundorf]

On Sunday 10 November 2013, Sune Vuorela wrote:
> On 2013-11-10, Kevin Ottens <ervin at kde.org> wrote:
> > --===============3596639883239406900==
> > Content-Type: multipart/signed; boundary="nextPart1424144.VkBYIHTjbs";
> > micalg="pgp-sha1"; protocol="application/pgp-signature"
> > 
> > 
> > --nextPart1424144.VkBYIHTjbs
> > Content-Transfer-Encoding: quoted-printable
> > Content-Type: text/plain; charset="iso-8859-1"
> > 
> > On Sunday 10 November 2013 17:12:02 Sune Vuorela wrote:
> >> Why move it out of e-c-m ?
> > 
> > To make e-c-m a neutral ground again, not something purely for KDE need=
> > s. I=20
> > can understand that positioning.
> 
> Let's just rename most of them to make them not look like kde specifics.
> Except kdeinstalldirs. But well. cmake has gnuinstalldirs and similar,
> so that could kind of be  okay to have.
> 
> Then there is the extremely dangerous KDECompilerSettings that should be
> renamed to LOLPleaseAddSurprisesIntoTheCMakeSetup. srsly. "I added a
> KDE Framework to my application and suddenly -DCMAKE_BUILD_TYPE=Debug is
> building with -O2". The other bits of the file seems to be filled with
> "Is this still needed?" "Does this work?"
> Should we consider sending it to the eternal bitfields?

Nothing in there was added without reason. If you can show for every single 
option why it was needed and why it is not needed anymore today I'm happy if 
it can be removed.
If you don't want to use these flags, don't load them. It is optional now, it 
wasn't optional in KDE4.
You don't get these flags by linking against a frameworks library.
You get these flags by including KDECompilerSettings.cmake, which the 
developer can chose to do or not to do.
 
> that leaves KDECMakeSettings which kind of could be renamed to
> 'PleaseUseSane2013Defaults' and thus no longer be KDE specific.
> We could then extend it in a couple of years if we need new changed sane
> defaults for 2015.

It is what we (KDE) consider sane defaults.
Settings in there are added and changed as we (KDE) see the need for it.
Not everybody considers these settings as appropriate, it depends on what you 
envision as environment for development and deployment. What is in there is 
good for KDEs needs.

The big thing is that the contents of these files depend on what we do and 
need in KDE SC.

Alex