KArchive for Qt4

[Alexander Neundorf]

On Saturday 17 November 2012, Sune Vuorela wrote:
> On 2012-11-17, Alexander Neundorf <neundorf at kde.org> wrote:
> > 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.
> >> 
> >> >> 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
> > 
> > What exactly is buggy in the file ?
> 
> at least the two following things (which is taken from memory, so there
> might be typing issues)
> 
> threadweaver_LIBRARY is just "threadweaver". I needed to figure out how
> to add LINK_DIRECTORIES(${threadweaver_DIR}) the right places as well.
> that was at least ... unexpected.

this is because the string "threadweaver" refers to the imported target with 
the name "threadweaver".
But, in kdelibs framework we still export all targets together in one big 
export set, instead in an individual one for each "framework".
This is the commented line 
#include("${CMAKE_CURRENT_LIST_DIR}/threadweaverTargets.cmake")

Now that cmake 2.8.10.1 is released, we can start exporting indivudual target 
files for each project.
Then "threadweaver" would refer to the imported target with the name 
"threadweaver", which has its full path set as a target property, so linking 
will just work.

I am about to change this once we have a concensus on how the "API" for 
developers should look like.
I'd like to get more input here e.g. also from you :-)
You can have a look at threadweaver now and before my commit, and let me know 
what you think about those changes, which are:
* setting the version variables
* creating a version header
* creating a twConfigVersion.cmake
* creating a twConfig.cmake file

> the variable for includes is not complete. you include most bits by
> doing include <threadweaver/foo>, but threadweaver/foo includes
> "threadweaver_export.h", so the threadweaver_INCLUDE_DIR variable isn't
> complete enough. I needed
> include_directories(${threadweaver_INCLUDE_DIR}
> ${threadweaver_INCLUDE_DIR}/threadweaver) to get it to be used.

Ok.
I'll take this as another argument for having the Config.cmake files local 
per-project, and not using a default one coming from cmake or e-c-m.

Alex