On Wednesday 27 February 2013 22:02:52 Alexander Neundorf wrote:
> Hi,
>
> I just pushed a change to kdelibs, which renames the libraries in tier1/ and
> tier2/ to CamelCase, e.g. we have now libKCoreAddons.so etc.
>
> Along with that extra-cmake-modules has been updated and is now at 0.0.8,
> this version is required now, both by kdelibs and plasma-frameworks.
>
> I hope I didn't mess up during the conflict merging.
> Let me know if something does not work.
>
> One more note:
> in plasma-frameworks I saw that you are using
> target_link_libraries(... KF5::karchive )
> etc., i.e. using the names of the imported targets directly.
> I am still undecided whether this is a good idea.
> Actually before I thought it would be good, now I'm leaning more toward not
> so good.
> The error I got with this was "ld: cannot find -lsolid"
> This looks like a normal library is not found, but the writer knew that this
> should be the name of an imported target, but there is nothing saying this
> in the command.
I don't get the problem. If you try to link to something that doesn't exist,
you get a "cannot find -lsolid" error, that's obvious. Of course KF5::solid
isn't a library name, it got replaced, but that's standard cmake behavior. If
I link to another target (from within the same project), it might not be the
lib name either. We never write -lsolid litterally (or libsolid.so), we write
a target name.
> All those failed, since the names changed, and they didn't fail at cmake
> time, but at link time :-/
> I changed all those (except those which I missed) to use variables again:
> ${Solid_LIBRARIES}, ${KWindowSystem_LIBRARIES} etc.
> If you make a typo there, it will be simply empty, and you can find out via
> debug messages.
... which means it will also fail at link time, not at cmake time.
So I don't see the point in this change. I'd must rather write KF5::Solid
than ${Solid_LIBRARIES}, where I can never remember if that's LIBRARY or
LIBRARIES, and Solid or SOLID, and where such variables come from, etc.
They look like an unnecessary additional layer on top...
> It also somewhat guards against changing names of the
> imported targets.
I don't expect this to happen too often ... and if it does, I'd much rather
see "-lsolid not found" than a linker error about symbols from solid being
missing, even though the variable is actually there in the
target_link_libraries line...
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Sponsored by BlueSystems and KDAB to work on KDE Frameworks
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
