On Thursday 28 February 2013, David Faure wrote:
> 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.
IMO there are two significant differences:
1) A wrong in-project target name will in general never build for the
developer.
A bad imported target name may build for the developer, but may not build for
a user (because the user has a different version of the package installed, or
because a find_package() is not checked properly, maybe there are more ways
how to get to that).
Yes, I am talking about hopefully rare error cases.
> > 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...
2) This may be good for the one who is currently working on the code.
It is a very different situation for somebody just trying to build the code.
He sees -lsolid and there is no reason why should not think that a libsolid.so
should have been found but wasn't.
Alex
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
