Sune Vuorela wrote:
> On 2012-11-18, Stephen Kelly <steve...@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.
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
