On Thursday 15 November 2012, Sune Vuorela wrote:
> On 2012-11-15, Alexander Neundorf <neund...@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
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
