KDE-buildsystem-basics package ?

[Stephen Kelly]

Alexander Neundorf wrote:
>> Then it would be used like this:
>> 
>> add_executable(foo ...)
>> ecm_mark_test(foo) # Explicitly mark foo as a test.
> 
> This should probably take a list of target names and be named
> "ecm_mark_as_test".
> 
> E.g.  -DTEST_SOURCE_DIR="\\"${CMAKE_CURRENT_SOURCE_DIR}/\\"" is purely a
> KDE convention. Also that those targets are not built by default is purely
> a KDE convention.
> This is what I mean when I say something is "KDE specific".
> 

KDE doing something for a long time or conventionally or conveniently 
doesn't make it KDE specific, and it doesn't make it a bad idea for everyone 
else. The opposite is true. It is a good idea to be able to not build tests 
with the all target (Qt also does this, albeit a slightly different way), 
but enable building them later, and it is a good idea to be able to refer to 
things in the source directory where relevant. Actually Qt5 can refer to 
things in the source, build and install directories as well as from 
resources in unit tests. That uses some macros and is exposed to 3rd parties 
for unit tests too. See:

https://qt.gitorious.org/qt/qtbase/commit/8481369f3d80d33aa9504e762c8a1cb28769e9be

> Both the test and the uninstall target have wiki pages dedicated to them:
> http://www.cmake.org/Wiki/CMakeEmulateMakeCheck
> http://www.cmake.org/Wiki/RecipeAddUninstallTarget
> 
> Whenever somebody suggested to add this to cmake directly, the reply was
> that it is well documented and so little code, no need to have it in
> cmake. We may though put them in e-c-m (ala boost).

Right.

> 
>> Which I prefer to
>> 
>> bar_add_executable(foo TEST ...)
>> 
>> because it doesn't pollute the API for adding executables with something
>> orthogonal (testing related stuff).
>> 
>> Setting the WIN32 and MACOS_BUNDLE parameters is also not needed in the
>> add_executable call, but can also be done with PROPERTIES.
> 
> Oh, I didn't know that. That must be "new" ;-)

:)

Also keep in mind that any perceived limitations are patchable. 

The documentation indicates that these things work as properties too, but I 
haven't tried them. Even if they don't work, we do have expertise to change 
CMake in sensible ways to remove any perceived roadblocks it has.

> 
>> If we can add to CMake something like:
>> 
>> set(CMAKE_GUI_EXECUTABLES 1) # CMake sets the platform specific gui
>>                              # properties on executable targets
> 
> The obvious thing to do would be to initialize them also from cmake
> variables, as other properties, i.e. from CMAKE_WIN32 and
> CMAKE_MACOS_BUNDLE. Hmm, OTOH this sounds actually like two quite generic
> variable names :-/
> 
> That must be discussed on the cmake-developers list.

Yes.

>> 
>> > INCLUDE_INSTALL_DIR must be set somewhere, and making it optional
>> > whether it comes from some package or defining it in the project itself
>> > will make for really ugly and long, i.e. hard to maintain,
>> > CMakeLists.txt in all the framework libraries.
>> 
>> I think INCLUDE_INSTALL_DIR is not a great example. It's very odd for it
>> to be anything other than 'include' right?
> 
> That's what I wondered too.
> Does it actually make sense to support modifying all of the install dirs ?

I don't know of any reason to be able to change the name of the 'include' 
directory or almost any other (with the exception of lib${LIB_PREFIX}).

> See my mail on the cmake-developers list from January 10th "RFC: standard
> (and not so standard) install dirs".

Yes, I saw that. Brad also suggested that installing the KDE conventional 
dirs from CMake:

Brad King wrote:
> Why not create a KDEInstallDirs.cmake that comes with CMake?  It wouldn't
> actually contain any KDE-specific code, just a documented layout standard
> that could be used by KDE project or outside projects that like the KDE
> install layout.

So it's not a completely wild idea :).

> 
> OTOH, if we come to a satisfying solution for creating the Config.cmake
> files, it doesn't hurt to have them configurable, see the "Making writing
> Config.cmake files easier - updated example" thread on kde-buildsystem.
> 
> Also, with GUNInstallDirs.cmake in CMake, they are also all configurable
> (because they are apparently all configurable with autotools), so it's
> probably ok.

Maybe so. In autotools it could be a historical feature of dubious value 
that no one has the guts to remove though. I don't know.

>> 
>> If it does break something the fix is simple. Either set the policy more
>> locally to the breakage, or port to unbroken use.
> 
> For now that's ok.
> But after KF5 has been released and new versions of cmake have been
> released, there will be the same situation again: there will be new
> policies added in cmake which change the behaviour and lead to the same
> problem again. If we continue to guarantee source compatibility, this
> means that e.g. policies such as CMP0005 (the quoting) must be kept at the
> same setting as they were with the first release of KF5.

What source compatibility do you mean? Do you mean frameworks should shield 
all downstreams from possible source incompatibilities introduced by CMake? 
(ie, introducing source compatibility where it doesn't really exist). You 
want to set all policies introduced by CMake after the release of KF5 to 
OLD?

Would it be enough to shield 'KDE applications' from those things and put 
'umbrella' policies in the 'umbrella' location? That would keep applications 
'source compatible' and keep frameworks 'high quality and modern'.

>> Aren't there other ways of executing the tests uninstalled without
>> scripts? I can run Grantlee tests uninstalled, and I don't have any
>> wrapper scripts.
> 
> Can you run them too if you set the option CMAKE_SKIP_RPATH to TRUE ?

Indeed they fail to run uninstalled if I set that variable in the cache.

./templates/tests/testbuiltins_exec: symbol lookup error: 
./templates/tests/testbuiltins_exec: undefined symbol: 
_ZNK8Grantlee8Variable11isLocalizedEv


> Under Windows it sets PATH, which can be worked around by generating
> executables and libraries into the same directory.
> 
> But yes, this is something which I think (i.e. not "know") which is barely
> used. OTOH I think e.g. debian packagers disable RPATH completely. So
> maybe they use it all the time.

Or maybe they run the tests after installation. Hopefully Sune can enlighten 
us.

>> > I don't like the idea of aliasing everything.
>> 
>> Ok. And why not? Because aliasing creates a difference between frameworks
>> and applications as I wrote above? Or something else?
> 
> I agree that those wrappers make sense for a compatibility file, like
> KDELibs4Compat.cmake, where the variables and macros are translated.
> 
> But if a macro comes from the package kcore and is named e.g.
> kcore_kdeinit_stuff(), aliasing it for everybody to kf5_kdeinit_stuff() is
> not a good idea. The "kcore" prefix would be correct. Having two different
> function calls which are exactly the same only obfuscates the code IMO.

Ok, so what I said above is pretty much correct. You don't like the 
difference between macros that application developers should use and 
frameworks should use.

> The only reason I see to alias it is for compatiblity.
> With the modularization I would expect that we expect developers become
> more aware of which KDE libraries they are actually using, and then we can
> assume that they know where the macros come from.

Given the discussions around modularization since the idea of frameworks has 
been discussed, I'm not so sure. KDE (application) developers don't want to 
know where the stuff comes from, and being forced to know would be uneasy.

> When I say "KDE specific" I mean this is behaviour we have because
> somebody in KDE wanted it that way, it is purely a KDE convention to do it
> this way. We should not masquerade it as something generic everybody
> wants.
> 
> When you say "KDE specific" you mean it depends in some way on some KDE
> technologgy.

Partly, I guess. Actually I disagree with your definition of KDE specific. 
It's not really accurate to say that things KDE has done for the last N 
years are always things that no one else wants. They need to be assessed on 
a case by case basis.

> When I say "e-c-m" I mean "stuff which does not depend on (the conventions
> of) KDE".
> When you say "e-c-m" you mean "stuff which has no technical/package
> dependencies to any other KDE packages".

Sort of I guess.

The above about dependencies is true, but really I think of ecm as an 
extension of CMake modules and macros where anything which enables other 
packages to have a better buildsystem solution is a candidate for inclusion 
(eg putting KDE buildsystem conventions in there, or boost conventions etc).

> 
> 
> I guess we can agree on some things:
> * we will not use GNUInstallDirs.cmake, because this is not what we need

Ok.

> * we will use our own set of install dirs, they will keep the names they
> have now

Ok.

> * these install dirs will be defined in a file named e.g.
> KDEInstallDirs.cmake 

Ok.

> * setting the compiler flags and build types will be
> in a file named e.g. KDECompilerSettings.cmake

Ok.

> * setting policies, RPATH, other cmake switches may go into a file
> KDEConventions.cmake or KDEDefaults.cmake

Maybe (the policies thing still doesn't seem right to me).

> * these files should be in the same location

Maybe. I think if it makes sense to put some in ECM (as general good ideas 
for Qt frameworks in general or KDE frameworks in particular), and some 
higher in the umbrella, then that should be considered.

The question of what goes where can only be answered fully by doing the 
work.

> * there may be a file which includes them all, on top of the frameworks
> package, for convenience. This may be in a different location.

Ok. That might invalidate my comment above, but I'll leave it in the email 
anyway. 

> Really, the clean way to distribute these files would be to have a package
> dedicated to them. They have a common purpose and a common community:
> serving as buildfiles for KDE software, developed by the KDE community.
> From that POV they would even be _the_ point which turns a Qt-based
> library into a KDE frameworks tier 1 library.

One of the goals from Randa was that tier1 stuff would be stuff that should 
in an ideal world be in Qt, but isn't for any number of valid reasons 
(barrier to entry, licensing etc) - ie, they should be closer to Qt than to 
KDE.

> e-c-m has different purpose and hopefully in the future also a different
> community: provide generally useful cmake extensions for everybody,
> hopefully with contributions from the cmake community.

Yes.

> 
> But this seems not to be popular (and I am also not really keen on having
> to deal with two packages), so maybe we can put the files mentioned above
> somewhere in ecm.

Right.

> 
> But, even if they go there, they will not use the ECM prefix, they will
> use the "KDE" or "KDE5" or "KF" prefix.
> We should at least separate them into their own directory.
> Then non-KDE users of e-c-m can look at ecm/modules/, and see generic
> macros. They can look at ecm/find-modules/ and they will see a bunch of
> generally useful find-modules, and they can look at ecm/kde-modules/, and
> see that this is KDE stuff, which they don't have to care about if they
> don't want to. If it's mixed up in the same directory, it may look to them
> like "well this is all KDE stuff, I don't want to touch it". This happens
> right now for the cmake modules we have in kdelibs/cmake/modules/,
> although only the ones which have "KDE" in their name are KDE-specific, it
> is not clear to many, also KDE, developers that the other files are
> completely independent from KDE. So let's have them clearly separated.

Fair enough. I do still think a lot of it is generally useful for Qt-non-KDE 
stuff (ECMQtFramework), but I think that's something we can compromise on. 
If needed, plain Qt only stuff can be refactored out in the future and 
source compatibly I'm sure.

> In the kernel they say that the kernel should provide the mechanics to do
> things, but not policies.
> Here it is similar.
> What I consider "KDE-specific" is policies. The mechanics are all already
> there.

Right, I see.

>> > (and this doesn't even consider the macros in KDE4Macros.cmake yet,
>> > which I did not write for the fun of it, but because people asked for
>> > the features).
>> 
>> Yes, and some of which could potentially be moved to other locations in a
>> modularized world, right?
> 
> As you said above, there are pros and cons.
> The big pro is that it is the right thing to do, there are two cons: it
> makes the work for "horizontal" people harder, and the macros will have
> their specific prefixes.
> 
> While for distributing the KDE-specific cmake files a separate package
> would be correct, putting them into e-c-m is more convenient.
> 
> While for the macros putting them with a common prefix into one central
> place would be more convenient, modularizing them too and giving them
> specific prefixes is the correct thing to do.

This also looks like a sensible area to compromise to make the stuff easier 
to manage and move forward with implementation.

> 
> I'd suggest coming to an agreement for the stuff in FindKDE4Internal.cmake
> and KDE4Defaults.cmake first, and where to put what, and after that we can
> go through the macros.

Sounds good to me.

Thanks,

Steve.