Re: [CMake] import/export and DLL's
On Wed, Dec 7, 2011 at 1:40 AM, Michael Wild them...@gmail.com wrote:
On 12/07/2011 01:49 AM, Totte Karlsson wrote:
Well, then just use add_definitions(-DIMPORT_X_DLL). If
-DEXPORT_X_DLL is present, it will override your export/import
header definitions for the import case, and everything should be
fine.
Not sure what you mean by override. If both symbols are defined,
MTK_COMMON will be defined as __declspec(dllexport) and not
__declspec(dllimport), since my headers have #elif, #not elses.
*That's* what I meant by _override_...
Using add_definitions makes sense however. I just started using CMake
two days ago and was not aware of that command.
Well, then you got a lot of RTFM'ing before you ;-)
CMake will only
add the DEFINE_SYMBOL when *building* the specified target, and
otherwise just leave it away.
When CMake invokes the compiler to *build* the DLL it adds
-DEXPORT_X_DLL. If the DLL is being *used* it doesn't do anything.
That is the problem. When you say it does not do anything,(in the
'use' case) it is in fact defining the dllimport flag (after your
#else).
The way my define structure looks, that does not happen.
Yes, and that is broken. Simple as that.
So, in your code you do something like this:
#ifdef EXPORT_A_DLL #define A_API __declspec(dllexport) #else
#define A_API __declspec(dllimport) #endif
No, I'm not doing that in my code. But I tried it, and together with
target_link_library everything compiles fine. In my opinion,
however, those #defines gives you something defined, without
defining anything.. that is a little too clever in my opinion. But
practical.
Not too clever; Common practice and actually recommended by Microsoft:
http://msdn.microsoft.com/en-us/library/8fskxacy.aspx
I'll try to see if that works. Right now I do have an
exporter/importer header and it is more complex and looks like
(for a target COMMON): #if defined(EXPORT_COMMON_DLL) #define
MTK_COMMON __declspec(dllexport) #elif defined(IMPORT_COMMON_DLL)
#define MTK_COMMON __declspec(dllimport) #elif
defined(EXPORT_COMMON_PKG) #define MTK_COMMON __declspec(package)
#elif defined(IMPORT_COMMON_PKG) #define MTK_COMMON
__declspec(package) #else #define MTK_COMMON #endif
Is this for embarcadero c++? in which case do you define
EXPORT_COMMON_DLL, and when do you use EXPORT_COMMON_PKG?
The package spec is a embarcadero flavor of a dll (that can be
installed in the IDE). That is why I need elseifs, and not just an
else.
So, __declspec(package) is used exactly when? Only when building the
DLL, only when using the DLL or in both cases? Assuming you only need it
when building, you could do the following in your CMakeLists.txt:
---
# loads of stuff...
# possibly detect this automatically using the BORLAND variable?
option(BUILD_EMBARCADERO_PACKAGE Build a bpl package OFF)
if(BUILD_EMBARCADERO_PACKAGE)
set(SYMBOL_SUFFIX PACKAGE)
else()
set(SYMBOL_SUFFIX DLL)
endif()
add_library(A SHARED a.cpp a.h)
add_library(B SHARED b.cpp b.h)
add_library(C SHARED c.cpp c.h)
target_link_libraries(B A)
target_link_libraries(C B)
foreach(t A B C)
set_target_properties(${t} PROPERTIES
DEFINE_SYMBOL ${t}_BUILD_${SYMBOL_SUFFIX})
endforeach()
# more stuff...
---
This defines TARGET_NAME_BUILD_{DLL,PACKAGE} when the target
TARGET_NAME is built, and otherwise nothing is defined. In your
headers you can then do something like the following (here for a.h, the
others are analogous):
---
#ifndef A_H
#define A_H
#if defined(A_BUILD_DLL)
#define A_API __declspec(dllexport)
#elif defined(A_BUILD_PACKAGE)
#define A_API __declspec(package)
#else
#define A_API __declspec(dllimport)
#endif
class A_API SuperDuperClass
{
// some stuff goes here...
};
#endif
---
HTH
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
See also the new in 2.8.6 module GenerateExportHeader:
http://cmake.org/cmake/help/cmake-2-8-docs.html#module:GenerateExportHeader
cmake --help-module GenerateExportHeader
HTH,
David
--
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] import/export and DLL's
On Dec 7, 2011, at 7:57 AM, David Cole wrote: See also the new in 2.8.6 module GenerateExportHeader: http://cmake.org/cmake/help/cmake-2-8-docs.html#module:GenerateExportHeader cmake --help-module GenerateExportHeader HTH, David -- +1 for that. Now to get all my developers to move to CMake 2.8.6 so I can jettison all my own code that did the same thing. Awesome addition. I also updated the wiki page at http://www.cmake.org/Wiki/BuildingWinDLL ___ Mike JacksonPrincipal Software Engineer BlueQuartz SoftwareDayton, Ohio mike.jack...@bluequartz.net www.bluequartz.net -- 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] import/export and DLL's
On 12/07/2011 03:57 PM, Michael Jackson wrote: On Dec 7, 2011, at 7:57 AM, David Cole wrote: See also the new in 2.8.6 module GenerateExportHeader: http://cmake.org/cmake/help/cmake-2-8-docs.html#module:GenerateExportHeader cmake --help-module GenerateExportHeader HTH, David -- +1 for that. Now to get all my developers to move to CMake 2.8.6 so I can jettison all my own code that did the same thing. Awesome addition. I also updated the wiki page at http://www.cmake.org/Wiki/BuildingWinDLL Really cool tool. +1! 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] import/export and DLL's
See also the new in 2.8.6 module GenerateExportHeader: http://cmake.org/cmake/help/cmake-2-8-docs.html#module:GenerateExportHeade r cmake --help-module GenerateExportHeader I see the header has this: #ifdef IS_STATIC_BUILD ... #else ... #endif Is there any way to generate this configured header for a static or for a shared build, so one doesn't have to add preprocessor defines to use the header file? -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- 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] import/export and DLL's
On 12/06/2011 09:47 AM, Totte Karlsson wrote:
Hi, I have a project where several DLL's are to be built, say A, B
and C. B needs to import functions/classes from A, and C need to
import functions from both A and B. In each library, a flag is
defined for exporting or importing, i.e. __declspec(dllexport) or
__declspec(import)
The build order is first A, then B and then C. I have defined build
flags in CMakeList.txt files as, in A for example
SET_TARGET_PROPERTIES (${target} PROPERTIES DEFINE_SYMBOL
EXPORT_A_DLL)
in B SET_TARGET_PROPERTIES (${target} PROPERTIES DEFINE_SYMBOL
EXPORT_B_DLL) SET_TARGET_PROPERTIES (${target} PROPERTIES
DEFINE_SYMBOL IMPORT_A_DLL)
and in C SET_TARGET_PROPERTIES (${target} PROPERTIES DEFINE_SYMBOL
EXPORT_C_DLL) SET_TARGET_PROPERTIES (${target} PROPERTIES
DEFINE_SYMBOL IMPORT_A_DLL) SET_TARGET_PROPERTIES (${target}
PROPERTIES DEFINE_SYMBOL IMPORT_B_DLL)
The only dll that seem to be built OK is A. In B and C, nothing seem
to be exported. Any tips on how to deal with this? I am using
CodeGear platform. Building static libs works fine.
-totte
You misunderstand and misuse the DEFINE_SYMBOL property. All the
IMPORT_X_DLL symbols are wrong, you have to remove them. CMake will only
add the DEFINE_SYMBOL when *building* the specified target, and
otherwise just leave it away.
So, in your code you do something like this:
#ifdef EXPORT_A_DLL
#define A_API __declspec(dllexport)
#else
#define A_API __declspec(dllimport)
#endif
For B and C the definitions are analogous.
HTH
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] import/export and DLL's
Thanks for feedback You misunderstand and misuse the DEFINE_SYMBOL property. All the IMPORT_X_DLL symbols are wrong, you have to remove them. But when building the B, and C dll the import symbols need to be defined somehow. See my export/import header below. CMake will only add the DEFINE_SYMBOL when *building* the specified target, and otherwise just leave it away. Not sure I understand. So, in your code you do something like this: #ifdef EXPORT_A_DLL #define A_API __declspec(dllexport) #else #define A_API __declspec(dllimport) #endif I'll try to see if that works. Right now I do have an exporter/importer header and it is more complex and looks like (for a target COMMON): #if defined(EXPORT_COMMON_DLL) #define MTK_COMMON __declspec(dllexport) #elif defined(IMPORT_COMMON_DLL) #define MTK_COMMON __declspec(dllimport) #elif defined(EXPORT_COMMON_PKG) #define MTK_COMMON __declspec(package) #elif defined(IMPORT_COMMON_PKG) #define MTK_COMMON __declspec(package) #else #define MTK_COMMON #endif Is the problem perhaps that the EXPORT_COMMON_DLL defined symbol is not undeffed so when the B DLL need to Import from A, it can't? TK For B and C the definitions are analogous. HTH 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 -- 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] import/export and DLL's
On 12/06/2011 10:42 AM, Totte Karlsson wrote: Thanks for feedback You misunderstand and misuse the DEFINE_SYMBOL property. All the IMPORT_X_DLL symbols are wrong, you have to remove them. But when building the B, and C dll the import symbols need to be defined somehow. See my export/import header below. Well, then just use add_definitions(-DIMPORT_X_DLL). If -DEXPORT_X_DLL is present, it will override your export/import header definitions for the import case, and everything should be fine. CMake will only add the DEFINE_SYMBOL when *building* the specified target, and otherwise just leave it away. Not sure I understand. When CMake invokes the compiler to *build* the DLL it adds -DEXPORT_X_DLL. If the DLL is being *used* it doesn't do anything. So, in your code you do something like this: #ifdef EXPORT_A_DLL #define A_API __declspec(dllexport) #else #define A_API __declspec(dllimport) #endif I'll try to see if that works. Right now I do have an exporter/importer header and it is more complex and looks like (for a target COMMON): #if defined(EXPORT_COMMON_DLL) #define MTK_COMMON __declspec(dllexport) #elif defined(IMPORT_COMMON_DLL) #define MTK_COMMON __declspec(dllimport) #elif defined(EXPORT_COMMON_PKG) #define MTK_COMMON __declspec(package) #elif defined(IMPORT_COMMON_PKG) #define MTK_COMMON __declspec(package) #else #define MTK_COMMON #endif Is this for embarcadero c++? in which case do you define EXPORT_COMMON_DLL, and when do you use EXPORT_COMMON_PKG? Is the problem perhaps that the EXPORT_COMMON_DLL defined symbol is not undeffed so when the B DLL need to Import from A, it can't? If you are referring to your original code, that was completely broken. As I explained above, if you have a structure like this add_library(A SHARED a.cpp) add_library(B SHARED b.cpp) target_link_libraries(B A) the following will happen: - A.cpp is compiled with -DA_EXPORTS. The DEFINE_SYMBOL property for target B is ignored. - DLL A is created - B.cpp is compiled with -DB_EXPORTS. The DEFINE_SYMBOL property for target A is ignored. - DLL B is created and linked against A To help you more, I would need to understand __declspec(package). The Embarcadero docs didn't really help me grasp its use... 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] import/export and DLL's
Read this article.
http://www.cmake.org/Wiki/BuildingWinDLL
If you have questions after that please post. That article should clear
everything up.
Thanks
___
Mike JacksonPrincipal Software Engineer
BlueQuartz SoftwareDayton, Ohio
mike.jack...@bluequartz.net www.bluequartz.net
On Dec 6, 2011, at 3:47 AM, Totte Karlsson wrote:
Hi,
I have a project where several DLL's are to be built, say A, B and C.
B needs to import functions/classes from A, and C need to import functions
from both A and B.
In each library, a flag is defined for exporting or importing, i.e.
__declspec(dllexport) or __declspec(import)
The build order is first A, then B and then C.
I have defined build flags in CMakeList.txt files as, in A for example
SET_TARGET_PROPERTIES (${target} PROPERTIES DEFINE_SYMBOL EXPORT_A_DLL)
in B
SET_TARGET_PROPERTIES (${target} PROPERTIES DEFINE_SYMBOL EXPORT_B_DLL)
SET_TARGET_PROPERTIES (${target} PROPERTIES DEFINE_SYMBOL IMPORT_A_DLL)
and in C
SET_TARGET_PROPERTIES (${target} PROPERTIES DEFINE_SYMBOL EXPORT_C_DLL)
SET_TARGET_PROPERTIES (${target} PROPERTIES DEFINE_SYMBOL IMPORT_A_DLL)
SET_TARGET_PROPERTIES (${target} PROPERTIES DEFINE_SYMBOL IMPORT_B_DLL)
The only dll that seem to be built OK is A. In B and C, nothing seem to be
exported.
Any tips on how to deal with this?
I am using CodeGear platform. Building static libs works fine.
-totte
--
.
Totte Karlsson, Ph.D.
Dune Scientific, LLC
425-296 1980 (office)
425-780 9648 (cell)
www.dunescientific.com
.
--
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
Re: [CMake] import/export and DLL's
Well, then just use add_definitions(-DIMPORT_X_DLL). If -DEXPORT_X_DLL is present, it will override your export/import header definitions for the import case, and everything should be fine. Not sure what you mean by override. If both symbols are defined, MTK_COMMON will be defined as __declspec(dllexport) and not __declspec(dllimport), since my headers have #elif, #not elses. Using add_definitions makes sense however. I just started using CMake two days ago and was not aware of that command. CMake will only add the DEFINE_SYMBOL when *building* the specified target, and otherwise just leave it away. When CMake invokes the compiler to *build* the DLL it adds -DEXPORT_X_DLL. If the DLL is being *used* it doesn't do anything. That is the problem. When you say it does not do anything,(in the 'use' case) it is in fact defining the dllimport flag (after your #else). The way my define structure looks, that does not happen. So, in your code you do something like this: #ifdef EXPORT_A_DLL #define A_API __declspec(dllexport) #else #define A_API __declspec(dllimport) #endif No, I'm not doing that in my code. But I tried it, and together with target_link_library everything compiles fine. In my opinion, however, those #defines gives you something defined, without defining anything.. that is a little too clever in my opinion. But practical. I'll try to see if that works. Right now I do have an exporter/importer header and it is more complex and looks like (for a target COMMON): #if defined(EXPORT_COMMON_DLL) #define MTK_COMMON __declspec(dllexport) #elif defined(IMPORT_COMMON_DLL) #define MTK_COMMON __declspec(dllimport) #elif defined(EXPORT_COMMON_PKG) #define MTK_COMMON __declspec(package) #elif defined(IMPORT_COMMON_PKG) #define MTK_COMMON __declspec(package) #else #define MTK_COMMON #endif Is this for embarcadero c++? in which case do you define EXPORT_COMMON_DLL, and when do you use EXPORT_COMMON_PKG? The package spec is a embarcadero flavor of a dll (that can be installed in the IDE). That is why I need elseifs, and not just an else. To help you more, I would need to understand __declspec(package). The Embarcadero docs didn't really help me grasp its use... The main difference compared to a regular DLL It gives the dll a handle to the main application I think. Embarcadero packages has .bpl as extension. It has nothing to do with why my dll could not get symbols from another dll. Well, seems that the target_link_libraries and the add_definitions did it! Thanks for your feedback! Totte -- 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] import/export and DLL's
On 12/6/2011 8:10 AM, Michael Jackson wrote:
Read this article.
http://www.cmake.org/Wiki/BuildingWinDLL
Yeah, I did start with that one. My main problem was (as M. Wild) pointed out,
defining the build flags correctly. I ended up using
add_definitions(-DEXPORT_MOLECULE_DLL)
In the article, the
SET_TARGET_PROPERTIES (MyLibrary PROPERTIES DEFINE_SYMBOL COMPILING_DLL )
construct is used. What is the difference?
Also, my dll's links to other dll's and that is not in the article. So I needed
to use target_link_libraries(...) for those.
I also had a more complex #define structure:
#if defined(EXPORT_COMMON_DLL)
#define MTK_COMMON __declspec(dllexport)
#elif defined(IMPORT_COMMON_DLL)
#define MTK_COMMON __declspec(dllimport)
#elif defined(EXPORT_COMMON_PKG)
#define MTK_COMMON __declspec(package)
#elif defined(IMPORT_COMMON_PKG)
#define MTK_COMMON __declspec(package)
#else
#define MTK_COMMON
#endif
forcing the user to #define everything needed. In the example that is not the
case since the dllimport is defined automatically if not building a dll.
I ended up changing my #define structure to
#if defined(EXPORT_COMMON_DLL)
#define MTK_COMMON __declspec(dllexport)
#elif defined(EXPORT_COMMON_PKG)
#define MTK_COMMON __declspec(package)
#elif defined(IMPORT_COMMON_PKG)
#define MTK_COMMON __declspec(package)
#else
#define MTK_COMMON __declspec(dllimport)
#endif
which is more user friendly.
Thanks for feedback,
Regards,
Totte
If you have questions after that please post. That article should clear
everything up.
Thanks
___
Mike JacksonPrincipal Software Engineer
BlueQuartz SoftwareDayton, Ohio
mike.jack...@bluequartz.net www.bluequartz.net
On Dec 6, 2011, at 3:47 AM, Totte Karlsson wrote:
Hi,
I have a project where several DLL's are to be built, say A, B and C.
B needs to import functions/classes from A, and C need to import functions from
both A and B.
In each library, a flag is defined for exporting or importing, i.e.
__declspec(dllexport) or __declspec(import)
The build order is first A, then B and then C.
I have defined build flags in CMakeList.txt files as, in A for example
SET_TARGET_PROPERTIES (${target} PROPERTIES DEFINE_SYMBOL EXPORT_A_DLL)
in B
SET_TARGET_PROPERTIES (${target} PROPERTIES DEFINE_SYMBOL EXPORT_B_DLL)
SET_TARGET_PROPERTIES (${target} PROPERTIES DEFINE_SYMBOL IMPORT_A_DLL)
and in C
SET_TARGET_PROPERTIES (${target} PROPERTIES DEFINE_SYMBOL EXPORT_C_DLL)
SET_TARGET_PROPERTIES (${target} PROPERTIES DEFINE_SYMBOL IMPORT_A_DLL)
SET_TARGET_PROPERTIES (${target} PROPERTIES DEFINE_SYMBOL IMPORT_B_DLL)
The only dll that seem to be built OK is A. In B and C, nothing seem to be
exported.
Any tips on how to deal with this?
I am using CodeGear platform. Building static libs works fine.
-totte
--
.
Totte Karlsson, Ph.D.
Dune Scientific, LLC
425-296 1980 (office)
425-780 9648 (cell)
www.dunescientific.com
.
--
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
Re: [CMake] import/export and DLL's
On 12/07/2011 01:49 AM, Totte Karlsson wrote:
Well, then just use add_definitions(-DIMPORT_X_DLL). If
-DEXPORT_X_DLL is present, it will override your export/import
header definitions for the import case, and everything should be
fine.
Not sure what you mean by override. If both symbols are defined,
MTK_COMMON will be defined as __declspec(dllexport) and not
__declspec(dllimport), since my headers have #elif, #not elses.
*That's* what I meant by _override_...
Using add_definitions makes sense however. I just started using CMake
two days ago and was not aware of that command.
Well, then you got a lot of RTFM'ing before you ;-)
CMake will only
add the DEFINE_SYMBOL when *building* the specified target, and
otherwise just leave it away.
When CMake invokes the compiler to *build* the DLL it adds
-DEXPORT_X_DLL. If the DLL is being *used* it doesn't do anything.
That is the problem. When you say it does not do anything,(in the
'use' case) it is in fact defining the dllimport flag (after your
#else).
The way my define structure looks, that does not happen.
Yes, and that is broken. Simple as that.
So, in your code you do something like this:
#ifdef EXPORT_A_DLL #define A_API __declspec(dllexport) #else
#define A_API __declspec(dllimport) #endif
No, I'm not doing that in my code. But I tried it, and together with
target_link_library everything compiles fine. In my opinion,
however, those #defines gives you something defined, without
defining anything.. that is a little too clever in my opinion. But
practical.
Not too clever; Common practice and actually recommended by Microsoft:
http://msdn.microsoft.com/en-us/library/8fskxacy.aspx
I'll try to see if that works. Right now I do have an
exporter/importer header and it is more complex and looks like
(for a target COMMON): #if defined(EXPORT_COMMON_DLL) #define
MTK_COMMON __declspec(dllexport) #elif defined(IMPORT_COMMON_DLL)
#define MTK_COMMON __declspec(dllimport) #elif
defined(EXPORT_COMMON_PKG) #define MTK_COMMON __declspec(package)
#elif defined(IMPORT_COMMON_PKG) #define MTK_COMMON
__declspec(package) #else #define MTK_COMMON #endif
Is this for embarcadero c++? in which case do you define
EXPORT_COMMON_DLL, and when do you use EXPORT_COMMON_PKG?
The package spec is a embarcadero flavor of a dll (that can be
installed in the IDE). That is why I need elseifs, and not just an
else.
So, __declspec(package) is used exactly when? Only when building the
DLL, only when using the DLL or in both cases? Assuming you only need it
when building, you could do the following in your CMakeLists.txt:
---
# loads of stuff...
# possibly detect this automatically using the BORLAND variable?
option(BUILD_EMBARCADERO_PACKAGE Build a bpl package OFF)
if(BUILD_EMBARCADERO_PACKAGE)
set(SYMBOL_SUFFIX PACKAGE)
else()
set(SYMBOL_SUFFIX DLL)
endif()
add_library(A SHARED a.cpp a.h)
add_library(B SHARED b.cpp b.h)
add_library(C SHARED c.cpp c.h)
target_link_libraries(B A)
target_link_libraries(C B)
foreach(t A B C)
set_target_properties(${t} PROPERTIES
DEFINE_SYMBOL ${t}_BUILD_${SYMBOL_SUFFIX})
endforeach()
# more stuff...
---
This defines TARGET_NAME_BUILD_{DLL,PACKAGE} when the target
TARGET_NAME is built, and otherwise nothing is defined. In your
headers you can then do something like the following (here for a.h, the
others are analogous):
---
#ifndef A_H
#define A_H
#if defined(A_BUILD_DLL)
#define A_API __declspec(dllexport)
#elif defined(A_BUILD_PACKAGE)
#define A_API __declspec(package)
#else
#define A_API __declspec(dllimport)
#endif
class A_API SuperDuperClass
{
// some stuff goes here...
};
#endif
---
HTH
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
