[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