Having a Tier 0 for cmake and git submodules

[David Faure]

On Monday 11 November 2013 01:06:33 Michael Pyne wrote:
> On Sun, November 10, 2013 20:11:07 David Faure wrote:
> > On Sunday 10 November 2013 13:44:09 Michael Pyne wrote:
> > > I would highly recommend doing something similar to what was done for
> > > strigi  when it was split into 5 git modules.
> > 
> > I think you misunderstood the issue?
> > 
> > A super-repo might help automating "building all of KF5", but it doesn't
> > solve the issue of "defining the install dirs and compiler settings in the
> > separate karchive tarball".
> > 
> > The stuff in the super-repo won't be in the karchive tarball, so it's
> > unrelated to the discussion in this thread, unless I'm missing something.
> 
> I believe the idea is that the karchive tarball would have an implicit
> dependency on a "KF5 umbrella" supermodule, no? 

No, not at all.

The KF5 umbrella thing is just a generic cmake file that allows to write 
find_package(KF5 COMPONENTS KArchive KIO etc.)
instead of 10 different find_package calls.
KArchive doesn't need this at all.
(Higher-tier frameworks might need it, but AFAICS they can also do without 
it).

The thing that we're considering a git submodule for, is these 3 files:
KDECMakeSettings.cmake  KDECompilerSettings.cmake  KDEInstallDirs.cmake

> I.e. what we're calling ECM
> now would be replaced by a "tier0"... although, re-reading Kévin's email, it
> seems that ECM would still be a separate dependency (but made generic) and
> that tier0 would be implicitly included with all tier1 repositories (or,
> *all* repositories?).

The above 3 files would be included in all repositories.

But again, my preferred option would be to rename them ECM and be done with it 
-- all this stuff is useful outside the KDE community. I'd certainly want to 
use that in any Qt app I would write professionally too:
* the actually working RPATH handling
* all the very sensible defaults like "include current dir", "enable automoc", 
"don't relink deps of shared libs"....
* the stricter compilation flags to get more warnings
  [after we fix the too-magic changing of the meaning of Debug]

OK, forcing -DQT_NO_CAST_FROM_ASCII on to apps is a bit over the top, I think 
we should actually revise that and only set it in the frameworks themselves.

And finally KDEInstallDirs.cmake can stay in ECM as is. One doesn't have to 
use it if one doesn't want kde install dirs.

> I have to admit I'd like that even less, if we're going to be making
> "one-stop git modules" for developer convenience I'd argue that we should
> replace ECM in that list of dependencies with Alex's proposed "KF5
> umbrella", which gives the same number of overall dependencies but still
> has the submodule magic (to hide the actual number of dependencies) and
> retains the generic/KDE split for CMake settings. As you mention elsewhere
> we'd still need to support a separate release of our KDE CMake build system
> files for third-party software to depend on.

I think you still misunderstand what the "KF5 umbrella" is, please take a look 
at kdelibs-frameworks/tier1/kf5umbrella.

If I try to factor out that name from your paragraph, I think what you're 
suggesting is a git supermodule that bundles ECM and KDE-ECM (the 3 KDE* files 
plus possibly KF5Config.cmake) into a single git module?

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5