Modified build system for itemmodels

[Alexander Neundorf]

Hi,

attached is a patch for kdelibs/tier1/itemmodels/.

It removes the usage of ECMQtFramework.cmake and uses instead the (new) cmake 
features directly.

The biggest difference is that itemmodels_version.h.in, 
itemmodelsConfig.cmake.in and itemmodelsUseFile.cmake.in are now part of 
itemmodels and also configured() directly in its CMakeLists.txt.

Despite of the code duplication (in trivial cases) this causes, why do I think 
this is better ?

Without the patch, all you see in the CMakeLists.txt is
include(ECMQtFramework)
without any following function/macro calls.

So, this basically doesn't tell the developer anything about what it does.
As result, he ends up with a bunch of created files in his build dir, which 
also get installed.

This IMO easily qualifies as "magic" most developers will not understand, they 
will not know where these files come from, what they are good for, what they 
should contain.

By having the
write_basic_package_version_file()
configure_package_config_file()
and
configure_file()

calls, followed by their respective install() calls directly in the 
CMakeLists.txt, it becomes immediately obvious where these generated files 
come from.
By having the .in files in the same directly, it makes it also much easier for 
the developer to have a look at them, and to understand them, especially since 
they are simpler now too (since they are less general).

Especially the FooConfig.cmake.in file should IMO not be provided somewhere, 
or generated automatically, since it can and should carry information specific 
to the respective project. That's way it is IMO not a good idea to provide a 
generic one in e-c-m. Developers will start to simply use it, which will keep 
them from learning what they can do with such files, and which information can 
and should be put in them.

The same probably applies for the Use-file.

We can discuss about providing some wrapper which in some way bundles the 
calls to write_basic_package_version_file(), configure_package_config_file()
and configure_file(), but it should be in a way that it stays obvious where 
the generated files come from, and easy for the developer to modify them 
depending on the project-specific needs.

In short: the Config.cmake files should be visible to the developer, this 
should make understanding them easier.

Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itemmodels.diff
Type: text/x-patch
Size: 4492 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120429/70b12043/attachment.diff>