[CMake] How to use DEFINE_SYMBOL properly?
Hilton Medeiros
medeiros.hilton at gmail.com
Tue Feb 9 11:03:54 EST 2010
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 <themiwi at 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.jackson at 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.jackson at bluequartz.net
> >>
> >> On Tue, Feb 9, 2010 at 8:59 AM, Hilton Medeiros
> >> <medeiros.hilton at 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.jackson at bluequartz.net> wrote:
> >>>
> >>>> http://www.cmake.org/Wiki/BuildingWinDLL
> >>>>
> >>>> _________________________________________________________
> >>>> Mike Jackson mike.jackson at 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
> >>>> <pgquiles at 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.hilton at 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
>
More information about the CMake
mailing list