KArchive for Qt4

[Stephen Kelly]

Sune Vuorela wrote:

> 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.

I think I misread what you wrote before. You meant 'kde modules', not 'ecm 
modules' AKA cmake files or macros.

> 
>> 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.

I'm not opposed to changing that (I think Alex wrote a replacement macro 
already), but I don't think just renaming the macro makes it more 
discoverable. If you didn't know the macro existed you'd still just be 
looking at a '${FOO_VERSION}' that comes from somewhere and start looking 
for a use of a macro with version in the name.

Anyway - Yes, the ecm API is not perfect yet and not ready for consumption 
by anyone yet. That will come though and I don't think it's something we 
need to spend a lot of time worrying about or discussing just yet.

Thanks,

Steve.