KArchive for Qt4

[Alexander Neundorf]

On Thursday 15 November 2012, Sune Vuorela wrote:
> On 2012-11-15, Alexander Neundorf <neundorf at kde.org> wrote:
> >> I thought we earlier agreed on things like "you should not inherit
> >> sonames from other modules" and such.
> 
> We have apparantly a ECM_SOVERSION coming from somewhere and used.

This comes from the call to
ecm_version(1.2.3)
in the top level of each framework, which sets
the variables ECM_VERSION_MAJOR, ECM_VERSION_MINOR, ECM_VERSION_PATCH, 
ECM_SOVERSION and ECM_VERSION_STRING .

This is one of the things I want to change, because:
* the names of the variables give the impression that they contain the version 
number of e-c-m
* the macro name ecm_version() misses a verb, so it is not obvious what it 
actually does


I have the following ideas:

1) add a macro which takes care of most version-related things:
* create a foo-version.h
* create a FooConfigVersion.cmake
* set some version variables as above

ecm_setup_version(1.2.3 HEADER foo-version.h
                        CMAKE FooConfigVersion.cmake
                        PREFIX FOO_ ) 

2)
* don't provide any macro which sets the version-related macros, but instead 
manually do
set(FOO_VERSION_MAJOR 1)
set(FOO_VERSION_MINOR 2)
set(FOO_VERSION_PATCH 3)
set(FOO_VERSION
   ${FOO_VERSION_MAJOR}.${FOO_VERSION_MINOR}.${FOO_VERSION_PATCH})
* use write_basic_package_version_file(FooConfigVersion.cmake
                                       VERSION ${FOO_VERSION}
                                COMPATIBILITY ANY_NEWER_VERSION)
* use configure_file(foo-version.h.in foo-version.h)


3) something inbetween ?

> >> and we just have layers of added complexity that seems to be added for
> >> the sake of complexity.
> > 
> > What do you mean exactly ?
> 
> We have a generated config file that I still haven't figured out where
> it comes from (and which is quite buggy and hard to fix where you don't
> know where it comes from)

It comes from include(ECMQtFramework).

This is the one big thing which I currently like least.
In Berlin Stephen and me agreed that this file will become completely project-
local, i.e. project foo will have a FooConfig.cmake.in which will be 
configured using configure_package_config_file().

While this is more work for somebody going through all modules/frameworks and 
adjusting things, it makes it very obvious where things come from and where 
something has to be changed if necessary.


> We have a find_package(KF5...) that does all sorts of unexpected magic
> We have magic install variables


Ok, FindKF5.cmake is currently still completely undocumented, this is true.
It supports components, including three "special" ones:
* "CMake", which loads e-c-m/kde-modules/KDECMakeSettings.cmake 
* "Compiler", which loads e-c-m/kde-modules/KDECompilerSettings.cmake 
* "InstallDirs", which loads e-c-m/kde-modules/KDEInstallDirs.cmake 

If you don't want this stuff from KDE, you can leave those components out and 
do it as you like.
This is a big improvement over kdelibs 4 where you simply always got 
everything.

With this, does it still feel "magic" to you ?
Avoiding the feeling of "magic" is one of my main goals.
I want to have the stuff as obvious as possible, even if this means more 
typing...

> but in all our magic, we have actually lost the
> CamelCase/ForwardingHeaders
> 
> and this is just after a short while of trying to use some bits.

Actually I'm really happy about input from some more people :-)

Alex