KArchive for Qt4

[Sune Vuorela]

On 2012-11-18, Stephen Kelly <steveire at gmail.com> wrote:
> Sune Vuorela wrote:
>> I'm currently trying to get threadweaver built separately (for qt4). and
>> the build system is way too complicated. and way too complex. and way
>> too wrong.
>> 
>> I thought we earlier agreed on things like "you should not inherit
>> sonames from other modules" and such.
>
> Do you have a link for this?

I don't have a link to 'you should not inherit sonames from other
modules'. but it sholud kind of be common sense as we also see in
various areas of current KDE land where e.g. libkmailprivate from kdepim
4.4 is not having a matching SONAME, but gets the SONAME from the
kdelibs it is built against.

> It's been made clear that the frameworks are not currently intended for use 
> yet, especially not without ecm, which is why it appeared too complicated, 
> complex and wrong to you while trying to take it out. 

I haven't tried to take ecm out, just to fix up bits where it didn't to
what I think it should. But I couldn't find where to fix.

> I also agree with 
> others who said we shouldn't ditch ecm.

I'm not at all suggesting to ditch ecm, but I am suggesting to make it
less hidden magic and more like a collection of tools. As in,
extra-cmake-modules, not extra-cmake-magic.

I am not at all new to cmake but I do have a hard time figuring out how
things are done. And that I think is a bit wrong.

apparantly, the ecm_version(x y z) command prefills some ECM_SOVERSION
and ECM_SOSTRING variables with x and x.y.z, which is not at all
obvious.

A simple way to make it much more readable would be having 

ecm_generate_soversion_vars(threadweaver x y z)

that generated a threadweaver_SOVERSION and threadweaver_SOSTRING
variables with x and x.y.z

While the resulting code is almost the same, the latter is much more
obvious and discoverable while the first one just look like magic.

/Sune