[cmake-developers] VISIBILITY_DEFAULT target property

[Stephen Kelly]

Brad King wrote:

> On 05/18/2013 06:18 AM, Stephen Kelly wrote:
>> I've pushed a VISIBILITY_DEFAULT-property topic to my clone. It adds a
>> VISIBILITY_DEFAULT target property which works similar to the
>> POSITION_INDEPENDENT_CODE property, and is intended to replace the try-
>> compiles in GenerateExportHeader.
> 
> Are there problems with the module that make a second solution worthwhile?

There are multiple flags which might go into the result variable, and 
currently they are one whitespace delimited string, but we'd like to move 
away from that and make a ';' delimited list. Or we could deprecate that 
'populate a variable somehow' solution and add a property.

There's also the argument of more control over the result. Current solution 
(after my branches are merged):

 add_compiler_export_flags(CXX CXX_EXPORT_FLAGS)

 # Can't do this because it would affect bat:
 #set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CXX_EXPORT_FLAGS}")

 add_library(foo ...)
 add_library(bar ...)
 add_library(bat ...)
 target_compile_definitions(foo PRIVATE ${CXX_EXPORT_FLAGS})
 target_compile_definitions(bar PRIVATE ${CXX_EXPORT_FLAGS})
 # Not bat.

Property based solution:

 # Not needed
 # add_compiler_export_flags

 set(CMAKE_DEFAULT_VISIBILITY hidden)
 
 add_library(foo ...)
 add_library(bar ...)
 add_library(bat ...)
 set_property(TARGET bat PROPERTY DEFAULT_VISIBILITY default)

It would even be possible to add a policy which changes the effect of 
add_compiler_export_flags (with no args) to just 

 set(CMAKE_DEFAULT_VISIBILITY hidden)

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.

> 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.

> What is the value in using a property for this?

As above.

>> 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?

Thanks,

Steve.