Everything can be made as an option, nobody would be forced to use this. In fact, this could be a macro with one 'target' argument. It would be your choice to use it:
add_visibility_definitions(target) It would choose the 'standard of visibility' to target_EXPORTS and target_IMPORTS, taking into account shared|static linking and the OS, the compiler, the compiler version... I can't remember any project that adds anything more but even in this case you can always concatenate the definitions, the basic is always the same. Kind regards, Hilton On Tue, 9 Feb 2010 16:24:20 +0100 Michael Wild <them...@gmail.com> wrote: > CMake can't possibly do this in a good and general way. I'd hate it > if it tried! > > 1. Many projects put much more stuff in the XXX_EXPORTS (or > whatever-it's-called) macros. There's a huge variability, no two > projects have the exact same requirements and conventions. > > 2. How would the > __declspec(import)/__attribute__(visibility("hidden")) come in if the > user-project doesn't use CMake but something else? > > There are probably many more issues of which I didn't think of... > > Michael > > On 9. Feb, 2010, at 16:05 , Hilton Medeiros wrote: > > > Well, that is exactly what I expect from CMake, it has > > done much more than this until now, this should be easy. > > > > As an example the library Ogre for 3D graphics rendering is > > known to support a lot of platforms and as you can see it is the > > same thing always: > > > > #if OGRE_PLATFORM == OGRE_PLATFORM_WIN32 > > # if defined( OGRE_STATIC_LIB ) > > # define _OgreExport > > # define _OgrePrivate > > # else > > # if defined( OGRE_NONCLIENT_BUILD ) > > # define _OgreExport __declspec( dllexport ) > > # else > > # if defined( __MINGW32__ ) > > # define _OgreExport > > # else > > # define _OgreExport __declspec( dllimport ) > > # endif > > # endif > > # define _OgrePrivate > > #endif > > > > #if OGRE_PLATFORM == OGRE_PLATFORM_LINUX || \ > > OGRE_PLATFORM == OGRE_PLATFORM_APPLE || \ > > OGRE_PLATFORM == OGRE_PLATFORM_IPHONE > > # if defined( OGRE_GCC_VISIBILITY ) > > # define _OgreExport __attribute__ ((visibility("default"))) > > # define _OgrePrivate __attribute__ ((visibility("hidden"))) > > # else > > # define _OgreExport > > # define _OgrePrivate > > # endif > > #endif > > > > They support every 'big' system like Windows, Linux, MacOS and > > mobiles like Symbian and Iphone, and even MinGW. > > > > Your example that they can change this in the future would mean a > > massive rebuild of thousands of projects. If CMake supported this, > > it would mean a fix in CMake and all the projects based on its > > build system would have no problems whatsoever. > > > > Kind regards, > > Hilton > > > > On Tue, 9 Feb 2010 09:23:19 -0500 > > Mike Jackson <mike.jack...@bluequartz.net> wrote: > > > >> Just to get some more clarification, what exactly do you mean by > >> "...this visibility macro turns out to be always the same thing in > >> every project...," > >> > >> The only thing you can say for certain is that for the versions of > >> Visual Studio and GCC _currently_ released the macros seem to stay > >> the same. There is absolutely NO guarantee that Microsoft, Apple, > >> GNU or someone else will NOT change that in the future. > >> > >> So right now the code that needs to be included in your project > >> via a header file is pretty much "boilerplate" code and is simple > >> and straight forward to insert into your project. > >> > >> Also, if you are converting another non-cmake project to CMake then > >> how that projects goes about implementing their visibility macros > >> may be different than how CMake chose to do it. > >> _________________________________________________________ > >> Mike Jackson mike.jack...@bluequartz.net > >> > >> On Tue, Feb 9, 2010 at 8:59 AM, Hilton Medeiros > >> <medeiros.hil...@gmail.com> wrote: > >>> Thanks a lot for the answers. > >>> > >>> Indeed, I already knew this macro, but I thought that since this > >>> visibility macro turns out to be always the same thing in every > >>> project, CMake would have it built in. I can't see why this is not > >>> the case yet. > >>> > >>> Well, back to #defines... > >>> > >>> Thanks again, > >>> Hilton > >>> > >>> On Tue, 9 Feb 2010 08:29:36 -0500 > >>> Mike Jackson <mike.jack...@bluequartz.net> wrote: > >>> > >>>> http://www.cmake.org/Wiki/BuildingWinDLL > >>>> > >>>> _________________________________________________________ > >>>> Mike Jackson mike.jack...@bluequartz.net > >>>> BlueQuartz Software www.bluequartz.net > >>>> Principal Software Engineer Dayton, Ohio > >>>> > >>>> > >>>> > >>>> On Tue, Feb 9, 2010 at 8:25 AM, Pau Garcia i Quiles > >>>> <pgqui...@elpauer.org> wrote: > >>>>> Hello, > >>>>> > >>>>> You are doing it wrong. You need to create a header file > >>>>> (myproject_exports.h, for instance) following > >>>>> http://gcc.gnu.org/wiki/Visibility . If you call your visibility > >>>>> macro target_EXPORTS, you do not need to modify the value of > >>>>> DEFINE_SYMBOL at all, CMake will automagically make use of it. > >>>>> You only need to do set_target_properties( target PROPERTIES > >>>>> DEFINE_SYMBOL my_visibility_macro ) if you want to use a > >>>>> different name for the macro (usually because it is an > >>>>> already-existing project which you are converting to CMake). > >>>>> > >>>>> On Tue, Feb 9, 2010 at 1:25 PM, Hilton Medeiros > >>>>> <medeiros.hil...@gmail.com> wrote: > >>>>>> Hello, > >>>>>> > >>>>>> From what I read and understood this DEFINE_SYMBOL property > >>>>>> should be defined like this (or something like this): > >>>>>> > >>>>>> On Windows, as shared library: > >>>>>> target_EXPORTS=__declspec(dllexport) On Linux, as shared > >>>>>> library: target_EXPORTS=__attribute__((visibility("default"))) > >>>>>> > >>>>>> > >>>>>> So that I can use this symbol like this: > >>>>>> > >>>>>> class target_EXPORTS ExampleClass {...}; > >>>>>> > >>>>>> > >>>>>> But on my machine (Linux, gcc) while building a shared library, > >>>>>> with CMake 2.8.0, I'm getting the error below because CMake is > >>>>>> defining this property with -Dtarget_EXPORTS=0: > >>>>>> > >>>>>> error: expected identifier before numeric constant > >>>>>> > >>>>>> What am I missing? > >>>>>> > >>>>>> Kind regards, > >>>>>> Hilton > >>>>>> _______________________________________________ > >>>>>> Powered by www.kitware.com > >>>>>> > >>>>>> Visit other Kitware open-source projects at > >>>>>> http://www.kitware.com/opensource/opensource.html > >>>>>> > >>>>>> Please keep messages on-topic and check the CMake FAQ at: > >>>>>> http://www.cmake.org/Wiki/CMake_FAQ > >>>>>> > >>>>>> Follow this link to subscribe/unsubscribe: > >>>>>> http://www.cmake.org/mailman/listinfo/cmake > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Pau Garcia i Quiles > >>>>> http://www.elpauer.org > >>>>> (Due to my workload, I may need 10 days to answer) > >>>>> _______________________________________________ > >>>>> Powered by www.kitware.com > >>>>> > >>>>> Visit other Kitware open-source projects at > >>>>> http://www.kitware.com/opensource/opensource.html > >>>>> > >>>>> Please keep messages on-topic and check the CMake FAQ at: > >>>>> http://www.cmake.org/Wiki/CMake_FAQ > >>>>> > >>>>> Follow this link to subscribe/unsubscribe: > >>>>> http://www.cmake.org/mailman/listinfo/cmake > >>>>> > >>> > >>> > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Follow this link to subscribe/unsubscribe: > > http://www.cmake.org/mailman/listinfo/cmake > _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake