Re: [CMake] Function for visibility definitions

2010-02-11 Thread Bill Hoffman

Hilton Medeiros wrote:

Wow, now you got me.
That is why I love discussions.
Thanks for your insight, now I (my hard-as-rock head) can understand
why this is not feasible.

As a side note I think this should be in a list, maybe in the wiki, to
advise others no to do this. A list of 'do not even think about this'.

I'm sorry for the incovenient.

Kind regards,
Hilton

On Thu, 11 Feb 2010 02:26:27 -0500
Mike Jackson mike.jack...@bluequartz.net wrote:


And what happens when a project wants to use my library? That
project must now use Cmake and your macro. What if a project
downstream can not use Cmake to define those macros? What then?



That said, you could have CMake configure a .h file that had this stuff 
in it.  It might be nice if the function did that automatically, as it 
is almost the same code for every project.  Then once your project was 
built with CMake, you would install the configured .h files and other 
build systems could still use the software.


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


Re: [CMake] Function for visibility definitions

2010-02-11 Thread Hendrik Sattler

Zitat von Bill Hoffman bill.hoff...@kitware.com:

That said, you could have CMake configure a .h file that had this stuff
in it.  It might be nice if the function did that automatically, as it
is almost the same code for every project.  Then once your project was
built with CMake, you would install the configured .h files and other
build systems could still use the software.


OTOH, cmake is a build system, not a code generator.
This export stuff is so simple[1], why all the hassle to generate it?

HS

[1]: you only have too cases: Windows and gcc=4. All compilers on  
Windows use the same syntax.



___
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


Re: [CMake] Function for visibility definitions

2010-02-11 Thread Michael Wild

On 11. Feb, 2010, at 15:40 , Hendrik Sattler wrote:

 Zitat von Bill Hoffman bill.hoff...@kitware.com:
 That said, you could have CMake configure a .h file that had this stuff
 in it.  It might be nice if the function did that automatically, as it
 is almost the same code for every project.  Then once your project was
 built with CMake, you would install the configured .h files and other
 build systems could still use the software.
 
 OTOH, cmake is a build system, not a code generator.
 This export stuff is so simple[1], why all the hassle to generate it?
 
 HS
 
 [1]: you only have too cases: Windows and gcc=4. All compilers on Windows 
 use the same syntax.
 

Also refer to http://gcc.gnu.org/wiki/Visibility

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


Re: [CMake] Function for visibility definitions

2010-02-11 Thread Hendrik Sattler

Zitat von Michael Wild them...@gmail.com:



On 11. Feb, 2010, at 15:40 , Hendrik Sattler wrote:


Zitat von Bill Hoffman bill.hoff...@kitware.com:

That said, you could have CMake configure a .h file that had this stuff
in it.  It might be nice if the function did that automatically, as it
is almost the same code for every project.  Then once your project was
built with CMake, you would install the configured .h files and other
build systems could still use the software.


OTOH, cmake is a build system, not a code generator.
This export stuff is so simple[1], why all the hassle to generate it?

HS

[1]: you only have too cases: Windows and gcc=4. All compilers on   
Windows use the same syntax.




Also refer to http://gcc.gnu.org/wiki/Visibility


...which can be even simplified to:
#if defined _WIN32 || defined __CYGWIN__
  #ifdef PROJECT_EXPORT
#define DLL_PUBLIC __declspec(dllexport)
  #endif
#else
  #if __GNUC__ = 4
#define DLL_PUBLIC __attribute__ ((visibility(default)))
#define DLL_LOCAL  __attribute__ ((visibility(hidden)))
  #endif
#endif
#ifndef DLL_PUBLIC
  #define DLL_PUBLIC
#endif
#ifndef DLL_LOCAL
  #define DLL_LOCAL
#endif

Note: __declspec(dllimport) is not used here as it is only to be used  
when including a header file for a DLL. This needs a different  
solution (some custom define) in the header, only.


You usually do not need DLL_LOCAL.

Additionally, if you want cross-language bindings, you may want an  
additional symbols file, so the symbol names are simpler. You also  
have to care about calling convention, then. So the defines above a  
only a small part of the deal.


HS


___
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


Re: [CMake] Function for visibility definitions

2010-02-11 Thread Clinton Stimpson

On 02/11/2010 07:40 AM, Hendrik Sattler wrote:

Zitat von Bill Hoffman bill.hoff...@kitware.com:

That said, you could have CMake configure a .h file that had this stuff
in it.  It might be nice if the function did that automatically, as it
is almost the same code for every project.  Then once your project was
built with CMake, you would install the configured .h files and other
build systems could still use the software.


OTOH, cmake is a build system, not a code generator.
This export stuff is so simple[1], why all the hassle to generate it?

HS

[1]: you only have too cases: Windows and gcc=4. All compilers on 
Windows use the same syntax.


If your library is only ever built as shared, sure, you don't cmake to 
generate code.

Otherwise, the code needs that bit of information from the build system.
I'd rather have a configured header file with that info in it.

Clint

___
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


Re: [CMake] Function for visibility definitions

2010-02-11 Thread Andreas Pakulat
On 11.02.10 16:09:34, Hendrik Sattler wrote:
 Zitat von Michael Wild them...@gmail.com:


 On 11. Feb, 2010, at 15:40 , Hendrik Sattler wrote:

 Zitat von Bill Hoffman bill.hoff...@kitware.com:
 That said, you could have CMake configure a .h file that had this stuff
 in it.  It might be nice if the function did that automatically, as it
 is almost the same code for every project.  Then once your project was
 built with CMake, you would install the configured .h files and other
 build systems could still use the software.

 OTOH, cmake is a build system, not a code generator.
 This export stuff is so simple[1], why all the hassle to generate it?

 HS

 [1]: you only have too cases: Windows and gcc=4. All compilers on   
 Windows use the same syntax.


 Also refer to http://gcc.gnu.org/wiki/Visibility

 ...which can be even simplified to:
 #if defined _WIN32 || defined __CYGWIN__
   #ifdef PROJECT_EXPORT
 #define DLL_PUBLIC __declspec(dllexport)
   #endif
 #else
   #if __GNUC__ = 4
 #define DLL_PUBLIC __attribute__ ((visibility(default)))
 #define DLL_LOCAL  __attribute__ ((visibility(hidden)))
   #endif
 #endif
 #ifndef DLL_PUBLIC
   #define DLL_PUBLIC
 #endif
 #ifndef DLL_LOCAL
   #define DLL_LOCAL
 #endif

 Note: __declspec(dllimport) is not used here as it is only to be used  
 when including a header file for a DLL. This needs a different solution 
 (some custom define) in the header, only.

At least Qt and KDE manage just fine with __declspec(dllimport) in their
xxx_export headers defining these macros. That is they define DLL_PUBLIC to
be __declspec(dllimport) when PROJECT_EXPORT is not defined and use the
fact, that cmake sets a define already when building a shared library.
(MAKE_XX_LIBRARY or something similar).

Andreas

-- 
Don't you feel more like you do now than you did when you came in?
___
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


Re: [CMake] Function for visibility definitions

2010-02-11 Thread Hendrik Sattler

Zitat von Clinton Stimpson clin...@elemtech.com:

If your library is only ever built as shared, sure, you don't cmake to
generate code.
Otherwise, the code needs that bit of information from the build system.
I'd rather have a configured header file with that info in it.


cmake already does that (equally to libtool).

HS


___
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


Re: [CMake] Function for visibility definitions

2010-02-10 Thread Hendrik Sattler
Am Mittwoch 10 Februar 2010 19:46:57 schrieb Hilton Medeiros:
 macro (check_gcc_visibility)
 include (CheckCXXCompilerFlag)
 check_cxx_compiler_flag(-fvisibility=hidden GCC_SUPPORTS_VISIBILITY)
 endmacro()

This macro does not check if gcc supports visibility but g++ instead.

 function (add_visibility_definitions)
 set (GCC_EXPORT __attribute__\(\(visibility\(\default\\)\)\))
 set (GCC_PRIVATE __attribute__\(\(visibility\(\hidden\\)\)\))
 set (WIN_EXPORT __declspec\(dllexport\))
 set (WIN_PRIVATE __declspec\(dllimport\))

Those are not correct: there is no equivalent of GCC_PRIVATE for MSVC.
What's wrong with a simple header file?

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


Re: [CMake] Function for visibility definitions

2010-02-10 Thread Christian Ehrlicher
Hilton Medeiros schrieb:
 Thanks for pointing that mistake, I fixed it.
 
 About g++: g++ is gcc with -lstdc++
 
 What is wrong with a simple CMake file?
 I know what is good about it, if CMake had it built in
 neither me nor any CMake user would need to write neither a simple
 header file nor a simple CMake file.
 
I don't see how this should work without a header file. How should i use
those defines in my source at all?
The better have a simple header-file...


Christian



signature.asc
Description: OpenPGP digital signature
___
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

Re: [CMake] Function for visibility definitions

2010-02-10 Thread Hilton Medeiros
Hello Christian,

thanks for the interest, let me explain:

## In your CMake file you could to do this:
...
include (VisibilityDefinitions)
add_visibility_definitions(PREFIX PROJECT)
...
##

// In your project source, this:
...
class PROJECT_EXPORTS ExampleClass {...};
...
//

It is really simple, the function will just add these
definitions, through CMake of course, in compile time like this:

g++ -DPROJECT_EXPORTS=__attribute__((visibility(default)))
-DPROJECT_PRIVATE=__attribute__((visibility(hidden)))
src/ExampleClass.cpp

But of course you won't see anything like this while compiling because
CMake shows only:
Building CXX object CMakeFiles/example.dir/src/ExampleClass.cpp.o

Also, by the signature of the function you could custom these
definitions just like you want them, like this:

add_visibility_definitions(PREFIX _MyLib
   EXPORT_SUFFIX Export
   PRIVATE_SUFFIX Private)

And in your source code:

class _MyLibExports ExampleClass {...};
class _MyLibPrivate ExampleClass {...};

Kind regards,
Hilton

On Thu, 11 Feb 2010 07:41:32 +0100
Christian Ehrlicher ch.ehrlic...@gmx.de wrote:
 Hilton Medeiros schrieb:
  Thanks for pointing that mistake, I fixed it.
  
  About g++: g++ is gcc with -lstdc++
  
  What is wrong with a simple CMake file?
  I know what is good about it, if CMake had it built in
  neither me nor any CMake user would need to write neither a simple
  header file nor a simple CMake file.
  
 I don't see how this should work without a header file. How should i
 use those defines in my source at all?
 The better have a simple header-file...
 
 
 Christian
 

___
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


Re: [CMake] Function for visibility definitions

2010-02-10 Thread Hilton Medeiros
Wow, now you got me.
That is why I love discussions.
Thanks for your insight, now I (my hard-as-rock head) can understand
why this is not feasible.

As a side note I think this should be in a list, maybe in the wiki, to
advise others no to do this. A list of 'do not even think about this'.

I'm sorry for the incovenient.

Kind regards,
Hilton

On Thu, 11 Feb 2010 02:26:27 -0500
Mike Jackson mike.jack...@bluequartz.net wrote:

 And what happens when a project wants to use my library? That
 project must now use Cmake and your macro. What if a project
 downstream can not use Cmake to define those macros? What then?
 
 Mike Jackson
 
 On Feb 11, 2010, at 2:04, Hilton Medeiros
 medeiros.hil...@gmail.com wrote:
 
  Hello Christian,
 
  thanks for the interest, let me explain:
 
  ## In your CMake file you could to do this:
  ...
  include (VisibilityDefinitions)
  add_visibility_definitions(PREFIX PROJECT)
  ...
  ##
 
  // In your project source, this:
  ...
  class PROJECT_EXPORTS ExampleClass {...};
  ...
  //
 
  It is really simple, the function will just add these
  definitions, through CMake of course, in compile time like this:
 
  g++ -DPROJECT_EXPORTS=__attribute__((visibility(default)))
 -DPROJECT_PRIVATE=__attribute__((visibility(hidden)))
 src/ExampleClass.cpp
 
  But of course you won't see anything like this while compiling
  because CMake shows only:
  Building CXX object CMakeFiles/example.dir/src/ExampleClass.cpp.o
 
  Also, by the signature of the function you could custom these
  definitions just like you want them, like this:
 
  add_visibility_definitions(PREFIX _MyLib
EXPORT_SUFFIX Export
PRIVATE_SUFFIX Private)
 
  And in your source code:
 
  class _MyLibExports ExampleClass {...};
  class _MyLibPrivate ExampleClass {...};
 
  Kind regards,
  Hilton
 
  On Thu, 11 Feb 2010 07:41:32 +0100
  Christian Ehrlicher ch.ehrlic...@gmx.de wrote:
  Hilton Medeiros schrieb:
  Thanks for pointing that mistake, I fixed it.
 
  About g++: g++ is gcc with -lstdc++
 
  What is wrong with a simple CMake file?
  I know what is good about it, if CMake had it built in
  neither me nor any CMake user would need to write neither a simple
  header file nor a simple CMake file.
 
  I don't see how this should work without a header file. How should
  i use those defines in my source at all?
  The better have a simple header-file...
 
 
  Christian
 
 
  ___
  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