Giordano Khouri <kgiord...@nikon.net> schrieb: >I am a firm believer that static libraries should have hidden >visibility. This is based on my experience on the Mac and may be >different in Linux.
This is about Windows, not Linux or Mac. Linking libraries works a bit different there. >A shared library (dylib, framework) can export a symbol that came in >from a static library as a private extern. If the symbol is extern >(visibility=default) in the static library, the shared library cannot >hide it unless the shared library is linked using an explicit list of >the symbols to export. A list of exports maybe isn't so bad for a small >to intermediate C library, but for any kind of C++ library, it's a huge >pain. The proper use of visibility avoids all that pain. > >The static library symbol visibility makes no difference when the >static library is linked into an executable. > >> -----Original Message----- >> From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On >> Behalf Of J Decker >> Sent: Thursday, October 31, 2013 3:27 PM >> To: Hendrik Sattler >> Cc: Matthew Woehlke; cmake@cmake.org >> Subject: Re: [CMake] Proper way to export a library >> >> something like.... (but probably mostly in a common header) >> >> if( IS_THIS_PROJECT ) >> if( UNIX or STATIC ) >> set( EXPORT ) # nothing, everything is exported by default; >gcc/unix >> else( UNIX or STATIC ) >> set( EXPORT __declspec(dllexport) ) >> endif( UNIX or STATIC ) >> else( IS_THIS_PROJECT ) >> # if something else includes this.... >> if( UNIX or STATIC ) >> set( EXPORT extern ) >> else( UNIX or STATIC ) >> set( EXPORT __declspec(dllimport) ) >> endif( UNIX or STATIC ) >> endif( IS_THIS_PROJECT ) >> >> On Thu, Oct 31, 2013 at 11:46 AM, Hendrik Sattler ><p...@hendrik-sattler.de> >> wrote: >> > >> > >> > Matthew Woehlke <matthew.woeh...@kitware.com> schrieb: >> >>On 2013-10-31 05:26, Cyrille Faucheux wrote: >> >>> Can you tell me a bit more about "implicit compile flags [...] >for >> >>imported >> >>> tagets"? >> >> >> >>See documentation on target_compile_definitions. >> >> >> >>> On the library I'm currently working on, with Visual Studio, I >have >> >>to >> >>> declare some compile definition in order to get the proper >> >>> "__declspec(dllimport)" or "__declspec(dllexport)" defined (or >not >> >>defined >> >>> when compiling/using a static version of this library). >> >> >> >>This sounds like you're doing it wrong. >> > >> > Not really as you can only cover the export import with this case >but not >> static vs. dynamic linking to that library with the same header file. >> > That it's usually solved with a define when linking statically >> > >> >>When building with CMake, the preferred way is to unconditionally >> >>define an ABI export symbol via a header which exists for that >purpose >> >>(e.g. >> >>config.h, my_package_exports.h, etc.). The value of the definition >> >>however is conditional on a symbol that is only defined when >building >> >>the library, to choose between import and export as appropriate. >> >> >> >>Even better, CMake will define <target>_EXPORTS for you when >building >> >>a >> >> >> >>library, so you shouldn't need to manually specify any definitions >at >> >>all. >> >> >> >>IOW you libraries headers would somewhere contain: >> >> >> >>#if defined(_WIN32) >> >># define MYPROJECT_ABI_EXPORT __declspec(dllexport) # define >> >>MYPROJECT_ABI_IMPORT __declspec(dllimport) #elif __GNUC__ >= 4 # >> >>define MYPROJECT_ABI_EXPORT __attribute__ ((visibility("default"))) ># >> >>define MYPROJECT_ABI_IMPORT __attribute__ ((visibility("default"))) >> >>#else # define MYPROJECT_ABI_EXPORT # define >> MYPROJECT_ABI_IMPORT >> >>#endif >> >> >> >>...and: >> >> >> >>#ifdef mylibrary_EXPORTS >> >># define MYLIBRARY_EXPORT MYPROJECT_ABI_EXPORT #else # define >> >>MYLIBRARY_EXPORT MYPROJECT_ABI_IMPORT #endif >> >> >> >> >> >>That said... >> >> >> >>> Does "implicit compile flags" means that those compile definition >> >>could be >> >>> automatically declared by the imported target? >> >> >> >>...this was my understanding of how >target_compile_definitions(PUBLIC) >> >>is supposed to work. (Note: I haven't actually used this feature >myself >> >> >> >>yet.) >> > >> > >> > -- >> > >> > Powered by www.kitware.com >> > >> > Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> > >> > Kitware offers various services to support the CMake community. For >more >> information on each offering, please visit: >> > >> > CMake Support: http://cmake.org/cmake/help/support.html >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html >> > CMake Training Courses: http://cmake.org/cmake/help/training.html >> > >> > Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> > >> > Follow this link to subscribe/unsubscribe: >> > http://www.cmake.org/mailman/listinfo/cmake >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For >more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://www.cmake.org/mailman/listinfo/cmake > > >Khouri Giordano >Software Technology Researcher > >Nikon Inc. >1300 Walt Whitman Road >Melville NY 11747-3064 > >Office: 631-547-4335 Fax: 631-547-0361 > >kgiord...@nikon.net www.nikonusa.com > > >CONFIDENTIAL: >This e-mail including any attachments is intended only for the party or >parties to whom it is addressed and may contain information which is >privileged and/or confidential. If you are not the intended recipient, >you are hereby notified that any use, disclosure, dissemination, >distribution, copying, or printing of any information contained in or >attached to this e-mail is STRICTLY PROHIBITED and may constitute a >breach of confidentiality and/or privilege. If you have received this >e-mail in error, please notify immediately the sender by reply e-mail >and then delete this e-mail and any attachments in their entirety from >your system. Thank you. This e-mail message including any attachments >is believed to be free of any viruses; however, it is the sole >responsibility of the recipient to ensure that it is virus free, and >Nikon does not accept any responsibility for any loss, disruption or >damage to your data or computer system which may occur in connection >with this e-mail including any attachments. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake