[CMake] How to use DEFINE_SYMBOL properly?

Hilton Medeiros medeiros.hilton at gmail.com
Tue Feb 9 10:05:45 EST 2010


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



More information about the CMake mailing list