KDE-buildsystem-basics package ?

[Stephen Kelly]

Alexander Neundorf wrote:

> On Saturday 21 January 2012, Stephen Kelly wrote:
>> Alexander Neundorf wrote:
> ...
>> >> 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.
> 
> ...until the 2.8.8 release I'd say.

Why the hard requirement already? If something we need or makes so much 
sense that we should use it, isn't it reasonable to depend on a later 
version?

There is also going to be some unsteadyness for the first couple of releases 
of the 5 series. I actually think we should allow ourselves to roll the 
CMake version dependency until we have overall stability. I don't see any 
reason to stick with what we use in 5.0.0 for years after. If with 5.1 or 
5.2 we see that we have everything we need from it for good stability, 
that's when we should freeze it.

>> >> 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.
> 
> Can you do that please ?

I guess. I don't know much about the subject though. I don't know enough 
about Mac/Windows.

>  
>> >> > 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}).
> 
> Wrong, since debian multiarch :-P
> From current GNUInstallDirs.cmake:

Yes, sorry I meant LIB_INSTALL_DIR I guess. I was referring to the multiarch 
stuff, but I don't know much about what it involves.

> 
>> > 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 :).
> 
> I wouldn't want that, because this would mean that in the case we need a
> new variable, we have to wait for the next cmake release, and then force
> everybody to update his cmake.

I don't mean adding it to CMake, but I mean the idea of having 'KDE stuff' 
be upstream *somewhere* is not a completely wild idea.

> ...
>> > 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.
> 
> I know.
> But if we move them to the modules, IMO they should get their correct
> names.

If they move to modules I agree that they should get names consistent with 
the modules that they are in.

You seem to be saying that you think that applications should use those same 
names and not use aliases.

I don't know. Maybe. We'd have to see the actual impact that has.

> 
> ...
>> > * 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).
> 
> Yes, how to handle the policies the best way is tricky. See also CMP0011.
> Let's keep handling the policies a separate issue.

Fair enough.

>> 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.
> 
> Well, if "should ideally be in Qt" is the definition, than qwt and qxt are
> qualify already right now ;-P
> 

Yes, exactly. Those libraries would be candidates for becoming 'KDE 
frameworks' in the same way that a C++ library can become a boost library, 
with the endorsement, review, maintenance and possibly API consistency that 
that involves. See Simon for a recent example of something that has moved 
into KDE. Making KDE frameworks be an attractive thing to be a part of for 
qwt and qxt is a goal. Even if they never decide to become part of the KDE 
frameworks community, that's the kind of thing that should be aimed for. 
Those libraries are widely used and liked. The same should be true for KDE 
frameworks.

This isn't really what this thread is about, but I wanted to jump on the 
opportunity to say that 'KDE should be the home of high quality 3rd party 
FOSS Qt libraries'.

> ...
>> > 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.
> 
> Ok.
> TODO:
> -e-c-m: create ecm/kde-modules/ - Alex
> -e-c-m: add KDEInstallDirs.cmake - Alex
> -e-c-m: add KDECompilerSettings.cmake - Alex
> -e-c-m: add KDEDefaults.cmake - Alex

> -CMake: initialize WIN32 and MACOSX_BUNDLE target from variables - Stephen
> -CMake: modify CMAKE_SKIP_RPATH behaviour ? Stephen

Ok, I can raise these issues.

> -CMake: simplify creating Config.cmake files - Yuri, Alex
> -CMake: handle imported targets in CMAKE_REQUIRED_LIBRARIES - Alex
> 
> 
> But, before doing this, which prefix should we use for the stuff in e-c-m
> ? "KDE", "KDE4", "KDE5" "KF", "KF5", "KF1", something else ?

KF5.

> FindKDE4.cmake uses "KDE4", FindKDE3.cmake uses "KDE3".
> I am in favour of having a version number in it (to make clear for which
> version it is). But I guess KDE5 is not really an option.
> 
> 
> Still not fully decided are the macros.

Right. Let's do what we can and then see what's left.

> Also, do we keep the cmake required version handling as it is now ?
> Right now the required version is defined in FindKDE4Internal.cmake. The
> idea was that if you are able to build kdelibs, you should be able to
> build all of KDE SC at least. And kdesupport must build anyway.
> So if kdelibs requires cmake 2.6.4, no package in kdesupport is allowed to
> require a higher version, and nothing in KDE SC is allowed to require a
> higher version.
> This makes a lot of sense for the scenario that the developer builds his
> complete KDE SC from scratch.
> Is this still our main scenario ?
> Or should we consider the case that somebody has KDE frameworks installed,
> and just builds something against it, the main target ?
> Then this wouldn't have to be that strict.
> 

I'm not sure. I'm not a fan of requiring that the CMake version we use must 
be several years/releases old. I also don't think we should depend on a new 
version of CMake each time it is released though. If we need features in a 
newer version, lets move to that newer version in a reasonable timeframe.

Thanks,

Steve.