[cmake-developers] VISIBILITY_DEFAULT target property

Brad King brad.king at kitware.com
Mon May 20 09:53:12 EDT 2013


On 05/20/2013 09:42 AM, Stephen Kelly wrote:
>  set(CMAKE_DEFAULT_VISIBILITY hidden)
>  
>  add_library(foo ...)
>  add_library(bar ...)
>  add_library(bat ...)
>  set_property(TARGET bat PROPERTY DEFAULT_VISIBILITY default)
> 
> I know this is only a bit nicer. It's an idea worth raising though if we 
> want to move away from strings for compile flags to lists of compile 
> options.

Thanks for the explanation.  (I assume you meant
s/DEFAULT_VISIBILITY/VISIBILITY_DEFAULT/ in your example.)

>> Unlike PIC, visibility is not a usage requirement, is it?
> 
> I'm not sure either. My vague understanding is that it might be needed for 
> plugins. That seems to be true for Windows, but I haven't checked on linux 
> yet. According to a comment in a KDE cmake file, it is apparently. kdelibs 
> fails at cmake time if Qt is not built with hidden visibility.

That sounds like the other way around.  Qt is a dependency of kdelibs.
If Qt wasn't built with hidden visiblity then kdelibs cannot change its
build to make things work.  It is more of a usage check/error.

>>> How should visibility-inlines-hidden be handled? Introduce
>>> CMAKE_${lang}_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN and use it if
>>> VISIBILITY_DEFAULT == "hidden"?
> 
> There is also an option for use with MinGW on Windows, which seems roughly 
> equivalent: -fno-keep-inline-dllexport. 
> 
> Could I make CMAKE_${lang}_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN apply 
> that too?

They do look quite similar.  Might there ever be a reason one would
want -fvisibility-inlines-hidden but not -fno-keep-inline-dllexport
on the respective platforms?

In my understanding of your proposal, VISIBILITY_DEFAULT == "hidden"
will add -fvisibility=hidden *and* -fvisibility-inlines-hidden.
Should we have a way to skip the latter e.g. "hidden-no-inlines"?

-Brad



More information about the cmake-developers mailing list