[CMake] Proposal: extra option PRIVATE for target_link_libraries

[Marcel Loose]

On Wed, 2009-12-23 at 13:09 +0100, Michael Wild wrote:
> On 23. Dec, 2009, at 12:08 , Marcel Loose wrote:
> 
> > Hi all,
> > 
> > I suggested this in the quite long thread "third party library
> > dependencies", but it may have been overlooked. Hence, I started a new
> > thread.
> > 
> > Upon (re)reading the Mandriva page
> > http://wiki.mandriva.com/en/Overlinking, I was thinking: maybe the issue
> > of overlinking can be solved more or less the same way as pkg-config
> > does: i.e. by defining private dependencies. This could be an extra
> > option to target_link_libraries. 
> > Something like:
> > 
> >  target_link_libraries(mylib public1 public2 PRIVATE private1 private2)
> > 
> > This would tell CMake that mylib directly depends on public1 and public2
> > and should only link in these two libraries when these are shared
> > object libraries; otherwise private1 and private2 would also need to be
> > added on the link line.
> > 
> > The big hurdle to take, of course, is to detect in a
> > platform-independent way whether the given library is shared or static.
> > However, a lot of this knowledge is already available in the diverse
> > Modules/Platform macros, so my feeling is that this should be feasible.
> > 
> > Best regards,
> > Marcel Loose.
> > 
> 
> You would also need a PUBLIC keyword, and then require that all FindXXX.cmake modules prefix their libraries with PUBLIC and PRIVATE. If only the PRIVATE libraries where prefixed, the following would not work if A_LIBRARIES contains PRIVATE:
> 
> find_package(A)
> find_package(B)
> add_library(C source.c)
> target_link_libraries(C ${A_LIBRARIES} ${B_LIBRARIES})
> 
> Because then all the B_LIBRARIES would be considered to be private "details" of the public A_LIBRARIES... Also, there's no way to tell CMake which of the private libraries belongs to which of the public libraries.
> 
> I think it would be better if a FindXXX.cmake module marked the private libraries as a property of the public libraries and then let CMake take it from there (although as of now I wouldn't know on what to set the property, except if the module created an IMPORTED target for each of the public libraries, but that bears the possibility of target name collisions with the importing project).
> 
> Michael

Hi Michael,

I don't think you'll need to prefix the library names with either
PRIVATE_ or PUBLIC_. CMake could figure out whether "public1" and
"public2" are shared or static libraries. If they are shared libraries,
then the libraries marked as private ("private1" and "private2") do not
have to be linked in as well. Otherwise they must also be linked in. I
assume that CMake keeps a list internally, of all dependent targets; the
private libs should only be added to that internal list if the public
libs are static libs.

I don't completely understand your example. Are you suggesting that
you'll run into trouble if you have a library named "PRIVATE"? I think
name clashes will currently occur as well if I name my library "debug",
"optimized", or "general".

Maybe, it would be better if the FindXXX modules would handle this. On
the other hand, you then depend on third parties to properly update
their FindXXX modules, or have to rewrite them yourselves :-(

Best regards,
Marcel Loose.