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 _BUILD_{DLL,PACKAGE} when the target
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
Re: [CMake] "make install" files
On 2011/12/6 20:43, Eric Noulard wrote: 2011/12/6 H Xu: Hello, In cmake, install command is used to indicate the files that need to be installed, and install(DIRECTORY ...) could be used to install directories. However, I can't find a way to install files in a directory EXCEPT a few files that I do not want to install. Is it possible to do this? May be using the PATTERN option + EXCLUDE see the doc from install(DIRECTORY dirs... DESTINATION [FILE_PERMISSIONS permissions...] [DIRECTORY_PERMISSIONS permissions...] [USE_SOURCE_PERMISSIONS] [OPTIONAL] [CONFIGURATIONS [Debug|Release|...]] [COMPONENT] [FILES_MATCHING] [[PATTERN | REGEX] [EXCLUDE] [PERMISSIONS permissions...]] [...]) http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:install Thanks. -- 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
___
Mike Jackson www.bluequartz.net
Principal Software Engineer mike.jack...@bluequartz.net
BlueQuartz Software Dayton, Ohio
On Dec 6, 2011, at 7:59 PM, Totte Karlsson wrote:
> 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?
The difference is that if you have existing code that already defined a symbol
for their import/export macros then you use the "SET_TARGET_PROPERTIES" call.
Otherwise let CMake define the symbol for you.
>
> 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 have a project that creates many sub libraries as part of the build. I have a
header file for each library that does all the definitions. Similar to this:
/* Cmake will define MXA_EXPORTS on Windows when it
configures to build a shared library. If you are going to use
another build system on windows or create the visual studio
projects by hand you need to define MXA_EXPORTS when
building the MXADatModel DLL on windows.
*/
#if defined (MXA_BUILT_AS_DYNAMIC_LIB)
#if defined (MXA_EXPORTS) /* Compiling the MXA DLL/Dylib */
#if defined (_MSC_VER) /* MSVC Compiler Case */
#define MXA_EXPORT __declspec(dllexport)
#elif (__GNUC__ >= 4) /* GCC 4.x has support for visibility options */
#define MXA_EXPORT __attribute__ ((visibility("default")))
#endif
#else /* Importing the DLL into another project */
#if defined (_MSC_VER) /* MSVC Compiler Case */
#define MXA_EXPORT __declspec(dllimport)
#elif (__GNUC__ >= 4) /* GCC 4.x has support for visibility options */
#define MXA_EXPORT __attribute__ ((visibility("default")))
#endif
#endif
#endif
/* If MXA_EXPORT was never defined, define it here */
#ifndef MXA_EXPORT
#define MXA_EXPORT
#endif
A couple of notes from above. I have a header file that gets configured where
the MXA_BUILT_AS_DYNAMIC_LIB is defined or not based on the value of
"BUILD_SHARED_LIBS" from CMake. CMake will define MXA_EXPORTS when MXA is built
as a shared library. So repeating this for each library in the project allows
my project to defined everything leaving nothing to be defined by a user of
this package.
>
> 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_D
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
> 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] New type of cache variable: lists
On Tue, Dec 6, 2011 at 5:13 PM, Robert Dailey wrote:
> Thanks for that info David.
You're welcome.
>
> I have to say that the way this is setup feels kind of duct-taped together.
It is kind of duct-taped together. (It was better than using WD-40...)
> I expected the documentation for such a feature to be under 'set' in the
> docs, but it wasn't.
Good idea to cross-link set and the STRINGS property. Too bad we don't
have a good way of specifying see also links in our documentation yet.
We are open to patches that clarify documentation when deficiencies
like this are noticed.
> Plus the option in the list that is the default must be
> specified in 2 different locations. I think a cleaner solution could be
> implemented:
>
> set( BaseName "binary;octal;decimal;hexidecimal" CACHE LIST "Documentation"
> )
>
> The first item in the list would be the default.
>
So you propose that
set( BaseName "binary;octal;decimal;hexidecimal" CACHE LIST "Documentation")
yields "${BaseName}" equal to "binary"?
That would be rather odd, since the existing:
set( BaseName "binary;octal;decimal;hexidecimal" CACHE STRING "Documentation")
yields "${BaseName}" equal to "binary;octal;decimal;hexidecimal"...
And everywhere else in the CMake documentation we treat STRING and
LIST as interchangeable entities, where a LIST is simply a string that
has semi-colon delimiters between the items of the list...
If we were to make a change like this to add to the "set" command, I'd
prefer to see something like the following:
set( BaseName "binary" CACHE STRING "Documentation"
CONSTRAIN_TO_STRINGS "binary;octal;decimal;hexidecimal")
The type of the cache entry in question is most definitely a STRING,
and furthermore in this case a non-list STRING. I don't think we want
it to be a list. We want to give a list of values to which to
constrain the string
> Wouldn't this work and be slightly cleaner and more straight-forward? Plus
> you could keep the documentation for this feature contained to the 'set'
> command in the docs like other cache variable types. I just don't think
> lists should be handled differently.
Perhaps you still need to make the mental leap that a list is a
string, and that a string is a list, in the CMake language?
David
>
> On Tue, Dec 6, 2011 at 3:32 PM, David Cole wrote:
>>
>> On Tue, Dec 6, 2011 at 4:26 PM, David Doria wrote:
>> > On Tue, Dec 6, 2011 at 4:19 PM, Robert Dailey
>> > wrote:
>> >> Has anyone thought of creating a "LIST" type for cache variables? In
>> >> CMake
>> >> GUI on Windows, this would be represented by a combo-box or drop-down
>> >> box
>> >> that allows the user to pick one item out of a list of available items.
>> >>
>> >> Is this possible?
>> >
>> > I definitely agree. An immediate use case is for the CMAKE_BUILD_TYPE
>> > variable. I added a feature request here a while back:
>> > http://public.kitware.com/Bug/view.php?id=11806
>> >
>> > 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
>>
>> From that bug report:
>>
>> For cmake-gui this can be done by setting the STRINGS property of
>> the cache entry:
>> set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS
>> "DEBUG;RELEASE;MY_BUILD_TYPE")
>>
>> And here's a blog about that feature:
>>
>> http://www.kitware.com/blog/home/post/82
>>
>> So, yes, Robert, it is possible. And David D., I'm not sure how we
>> could make it automatic as you request in the bug report.
>>
>>
>> HTH,
>> David C.
>
>
--
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
[CMake] Question about add_custom_target
Does $ work in add_custom_target as it does in add_custom_command? The documentation doesn't state anything about this that I can see, but it seems like it should work. - Robert Dailey -- 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] New type of cache variable: lists
Thanks for that info David. I have to say that the way this is setup feels kind of duct-taped together. I expected the documentation for such a feature to be under 'set' in the docs, but it wasn't. Plus the option in the list that is the default must be specified in 2 different locations. I think a cleaner solution could be implemented: set( BaseName "binary;octal;decimal;hexidecimal" CACHE LIST "Documentation" ) The first item in the list would be the default. Wouldn't this work and be slightly cleaner and more straight-forward? Plus you could keep the documentation for this feature contained to the 'set' command in the docs like other cache variable types. I just don't think lists should be handled differently. - Robert Dailey On Tue, Dec 6, 2011 at 3:32 PM, David Cole wrote: > On Tue, Dec 6, 2011 at 4:26 PM, David Doria wrote: > > On Tue, Dec 6, 2011 at 4:19 PM, Robert Dailey > wrote: > >> Has anyone thought of creating a "LIST" type for cache variables? In > CMake > >> GUI on Windows, this would be represented by a combo-box or drop-down > box > >> that allows the user to pick one item out of a list of available items. > >> > >> Is this possible? > > > > I definitely agree. An immediate use case is for the CMAKE_BUILD_TYPE > > variable. I added a feature request here a while back: > > http://public.kitware.com/Bug/view.php?id=11806 > > > > 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 > > From that bug report: > > For cmake-gui this can be done by setting the STRINGS property of > the cache entry: > set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS > "DEBUG;RELEASE;MY_BUILD_TYPE") > > And here's a blog about that feature: > > http://www.kitware.com/blog/home/post/82 > > So, yes, Robert, it is possible. And David D., I'm not sure how we > could make it automatic as you request in the bug report. > > > HTH, > David C. > -- 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] hear hear
On 6 December 2011 17:19, Alexander Neundorf wrote: > On Tuesday 06 December 2011, Mateusz Łoskot wrote: >> On 6 December 2011 16:27, Daniel Dekkers wrote: >> > On Dec 4, 2011, at 11:59 AM, Michael Jackson wrote: >> >> I think if the CMake community took a vote we could probably come up >> >> with an "Exemplar" Find*.cmake file that is good for someone trying to >> >> develop a new one. >> > >> > Yes please. >> > And I think in general that is true. Of course it is more interesting and >> > often more urgent to spend time on "exotic" problems. But there are >> > these basics that are missing in the documentation. >> >> It's a great idea and I've been suggesting and looking for best >> practices for long time: >> >> http://www.cmake.org/pipermail/cmake/2010-March/035596.html >> >> I'd add also: >> >> Find*.cmake modules should be documented separately (separate >> chapters/pages) from the main documentation. The current documentation is >> already very long and navigating it has become difficult. > > Do you mean the book or the man/html pages ? I meant the Web version: http://cmake.org/cmake/help/cmake-2-8-docs.html But, it turns I'm wrong, as the HTML version installed with CMake is well organised. For example, on Windows users get: %ProgramFiles%/CMake 2.8/doc/cmake-2.8/cmake-modules.html False complain, apologies. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org -- 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] New type of cache variable: lists
On Tue, Dec 6, 2011 at 4:26 PM, David Doria wrote: > On Tue, Dec 6, 2011 at 4:19 PM, Robert Dailey wrote: >> Has anyone thought of creating a "LIST" type for cache variables? In CMake >> GUI on Windows, this would be represented by a combo-box or drop-down box >> that allows the user to pick one item out of a list of available items. >> >> Is this possible? > > I definitely agree. An immediate use case is for the CMAKE_BUILD_TYPE > variable. I added a feature request here a while back: > http://public.kitware.com/Bug/view.php?id=11806 > > 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 >From that bug report: For cmake-gui this can be done by setting the STRINGS property of the cache entry: set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS "DEBUG;RELEASE;MY_BUILD_TYPE") And here's a blog about that feature: http://www.kitware.com/blog/home/post/82 So, yes, Robert, it is possible. And David D., I'm not sure how we could make it automatic as you request in the bug report. HTH, David C. -- 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] New type of cache variable: lists
On Tue, Dec 6, 2011 at 4:19 PM, Robert Dailey wrote: > Has anyone thought of creating a "LIST" type for cache variables? In CMake > GUI on Windows, this would be represented by a combo-box or drop-down box > that allows the user to pick one item out of a list of available items. > > Is this possible? I definitely agree. An immediate use case is for the CMAKE_BUILD_TYPE variable. I added a feature request here a while back: http://public.kitware.com/Bug/view.php?id=11806 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
[CMake] New type of cache variable: lists
Has anyone thought of creating a "LIST" type for cache variables? In CMake GUI on Windows, this would be represented by a combo-box or drop-down box that allows the user to pick one item out of a list of available items. Is this possible? - Robert Dailey -- 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] Best practices/preferred methods for linking external libraries
On Tue, Dec 6, 2011 at 12:08 PM, Matthew LeRoy wrote: > On 2011-12-03 14:54-0800 Alan W. Irwin wrote: >> >> On 2011-12-03 12:42-0800 Alan W. Irwin wrote: >> >> > On 2011-12-02 19:33- Matthew LeRoy wrote: >> >> Assuming we want to just put the install tree in version control >> >> somewhere, and have ProjectB's list files reference the install tree >> >> out of version control, is writing a Find module the best way to do >> >> that? >> > >> > I don't see any way your highly unusual use case could work unless you >> > adopt a common installation prefix for projectA that everybody can use >> > on their various systems. >> >> Hi Matt: >> >> On second thought I got too negative about your strange use case, and to >> answer your question directly for that case, yes, with a Find module written >> for ProjectA, then your ProjectB users can install ProjectA anywhere, and if >> they set CMAKE_LIBRARY_PATH and CMAKE_INCLUDE_PATH properly, they _should_ be >> able to get the Find module to find libraries, headers, etc., from ProjectA >> regardless of where it is installed. >> >> That said, I am still a little surprised you are not taking the traditional >> independent software package approach for ProjectA. >> >> Alan > > Alan: > > I explained a little further (hopefully clearer?) what I'm trying to > accomplish > in another reply, here: > http://www.cmake.org/pipermail/cmake/2011-December/047897.html. > > A further clarification would be that ProjectA is not intended to be > distributed > publicly on it's own at all; it will only ever be distributed as part of > another > project which uses it (ProjectB, for example). Essentially, it's just an > independent, > reusable sub-component that we want to develop in isolation. > > Here's something like what I was envisioning with putting the binary > distribution > in the source tree for ProjectB (many things omitted): > > /ProjectB > |--CMakeLists.txt > |--/src > |--/test > `--/lib > |--/bin > | `--libProjectA.so > `--/include > `--/ProjectA > `--*ProjectA headers here* > > The idea, then, would be that whenever we want B to use a new version of A, > we just drop the new .so and includes for A overtop of the existing ones in > the > source tree and commit them. > > So, the question is, what's the best way to get B's CMakeLists.txt files to > find > and use A from within B's own source tree? A Find*.cmake module for A? > > Or, do you recommend a different approach entirely? > > Matt > -- > > 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 You don't need a Find* anything for a scenario like this. The best way to do this is simply to encode the knowledge of the location of A's files in your B project CMakeLists files. 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] hear hear
On Tuesday 06 December 2011, Mateusz Łoskot wrote: > On 6 December 2011 16:27, Daniel Dekkers wrote: > > On Dec 4, 2011, at 11:59 AM, Michael Jackson wrote: > >> I think if the CMake community took a vote we could probably come up > >> with an "Exemplar" Find*.cmake file that is good for someone trying to > >> develop a new one. > > > > Yes please. > > And I think in general that is true. Of course it is more interesting and > > often more urgent to spend time on "exotic" problems. But there are > > these basics that are missing in the documentation. > > It's a great idea and I've been suggesting and looking for best > practices for long time: > > http://www.cmake.org/pipermail/cmake/2010-March/035596.html > > I'd add also: > > Find*.cmake modules should be documented separately (separate > chapters/pages) from the main documentation. The current documentation is > already very long and navigating it has become difficult. Do you mean the book or the man/html pages ? For man/html-pages, additionally to the all-in-one cmake.html (or man page), there are also splitted man/html-pages: man cmakemodules man cmakecommands man cmakeprops man cmakepolicies Is that what you mean ? Alex -- 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] hear hear
On 6 December 2011 16:27, Daniel Dekkers wrote: > On Dec 4, 2011, at 11:59 AM, Michael Jackson wrote: >> I think if the CMake community took a vote we could probably come up with an >> "Exemplar" >> Find*.cmake file that is good for someone trying to develop a new one. > > Yes please. > And I think in general that is true. Of course it is more interesting and > often more > urgent to spend time on "exotic" problems. But there are these basics that > are missing in the documentation. It's a great idea and I've been suggesting and looking for best practices for long time: http://www.cmake.org/pipermail/cmake/2010-March/035596.html I'd add also: Find*.cmake modules should be documented separately (separate chapters/pages) from the main documentation. The current documentation is already very long and navigating it has become difficult. Adding guidelines for Find*.cmake modules will make it close to impossible to use. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org -- 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] Best practices/preferred methods for linking external libraries
On 2011-12-03 14:54-0800 Alan W. Irwin wrote: > > On 2011-12-03 12:42-0800 Alan W. Irwin wrote: > > > On 2011-12-02 19:33- Matthew LeRoy wrote: > >> Assuming we want to just put the install tree in version control > >> somewhere, and have ProjectB's list files reference the install tree > >> out of version control, is writing a Find module the best way to do > >> that? > > > > I don't see any way your highly unusual use case could work unless you > > adopt a common installation prefix for projectA that everybody can use > > on their various systems. > > Hi Matt: > > On second thought I got too negative about your strange use case, and to > answer your question directly for that case, yes, with a Find module written > for ProjectA, then your ProjectB users can install ProjectA anywhere, and if > they set CMAKE_LIBRARY_PATH and CMAKE_INCLUDE_PATH properly, they _should_ be > able to get the Find module to find libraries, headers, etc., from ProjectA > regardless of where it is installed. > > That said, I am still a little surprised you are not taking the traditional > independent software package approach for ProjectA. > > Alan Alan: I explained a little further (hopefully clearer?) what I'm trying to accomplish in another reply, here: http://www.cmake.org/pipermail/cmake/2011-December/047897.html. A further clarification would be that ProjectA is not intended to be distributed publicly on it's own at all; it will only ever be distributed as part of another project which uses it (ProjectB, for example). Essentially, it's just an independent, reusable sub-component that we want to develop in isolation. Here's something like what I was envisioning with putting the binary distribution in the source tree for ProjectB (many things omitted): /ProjectB |--CMakeLists.txt |--/src |--/test `--/lib |--/bin | `--libProjectA.so `--/include `--/ProjectA `--*ProjectA headers here* The idea, then, would be that whenever we want B to use a new version of A, we just drop the new .so and includes for A overtop of the existing ones in the source tree and commit them. So, the question is, what's the best way to get B's CMakeLists.txt files to find and use A from within B's own source tree? A Find*.cmake module for A? Or, do you recommend a different approach entirely? Matt -- 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
[CMake] hear hear
On Dec 4, 2011, at 11:59 AM, Michael Jackson wrote: > I think if the CMake community took a vote we could probably come up with an > "Exemplar" Find*.cmake file that is good for someone trying to develop a new > one. Yes please. And I think in general that is true. Of course it is more interesting and often more urgent to spend time on "exotic" problems. But there are these basics that are missing in the documentation. Like,.. this works in 99% of the cases, we, CMake, advise you to do this. If you don't, you are making life hard on yourself and you are more or less on your own. Something like: 1) a single executable 2) a single executable linked to a lib built from source 3) different executables using the same lib built from source 4) a single executable linked to a binary lib (with the aid of a find module) ... n) multiple executables linked to multiple libraries (linked to third-party libraries), some static, some dynamic, some with their own CMake builds, some without, on different platforms. Auch. n+1) making anything work with Xcode "Buy the book" is a good response of course. But people don't do that, until 3 months later. Thanks, Daniel -- 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] Best practices/preferred methods for linking external libraries
On Dec 6, 2011, at 9:56 AM, Matthew LeRoy wrote: > On Dec 5, 2011, at 5:57 PM, Michael Jackson wrote: > >> On Dec 5, 2011, at 5:36 PM, Matthew LeRoy wrote: >> >>> On Dec 4, 2011, at 11:59 AM, Michael Jackson wrote: >>> On Dec 1, 2011, at 4:56 PM, Matthew LeRoy wrote: > We began using CMake a few months ago for a couple of small cross- >> platform projects, and we're still > learning all the ins and outs and capabilities CMake has to offer, as >> well as how to get the most > out of CMake by using it "The Right Way". Right now, we're trying to >> figure out how to link > to external libraries that don't have "find" modules or CMake config-mode >> files. After lots of > reading in the wiki, mailing list, etc, it seems like there are several >> different ways to do > this, like writing "find" modules and/or config-mode files ourselves, >> using the LINK_DIRECTORIES() > command, importing/exporting targets, and others. What we're unsure of >> is, what is the "preferred" > or "officially supported" method? > > To be a little more specific, we have two different library projects >> (call them ProjectA and > ProjectB) that both use CMake, but are developed independently. Further, >> ProjectB depends (or will > depend) on ProjectA; we've just recently gotten to the point on ProjectB >> where we want to use some > of the functionality in ProjectA, so we need to link to the ProjectA >> library(ies). At first we > thought we needed to write a "find" module for ProjectA -- but we really >> have very little idea how > to go about doing that. Other than the wiki page for finding libraries >> that talks a little about > writing "find" modules >> (http://www.vtk.org/Wiki/CMake:How_To_Find_Libraries), is there any other > documentation for writing a proper "find" module? Is there a particular >> module that ships with CMake > that is well-written that we should look at as a guide? I had a project that I developed a few years back which was very close to >> your situation. My project, call it "MXA", was the base library that got used >> in a number of other projects. What I ended up doing was creating a >> "FindMXA.cmake" file that got configured during the actual build of MXA to >> make sure all the proper library names and location of resource files were >> set correctly. Then I would install the MXA project into an external location >> on my system, say /Users/Shared/Toolkits (OS X). I would manually copy the >> FindMXA.cmake file to the other projects so that they could have the find >> module available. In the beginning this made for a lot of manual copying when >> MXA was changing a bunch but once MXA settled down to a consistent naming >> scheme the "FindMXA.cmake" file never changed and so I found I did not have >> to update the "FindMXA.cmake" file in the other projects that depended on >> MXA. I think in more recent years the CMake developers would rather see people >> create the CMake Export files instead of developing the Find* module for my >> project. In the end I just didn't have the time to properly investigate and >> implement the CMake Export file so I never did it. I think if the CMake community took a vote we could probably come up with >> an "Exemplar" Find*.cmake file that is good for someone trying to develop a >> new one. The issues that arise are that each of the projects that have a >> "Find*.cmake" file are usually different in subtle ways which leads to issues >> when you try to simply "copy/paste" from an existing module to create a new >> module. It really just depends on what your "ProjectA" has installed. I am >> going to provide my current "FindMXA.cmake" file at the end of this email and >> leave it open for criticism/corrections. Maybe it will spur a conversation >> that we can all benefit from. >>> >>> Believe it or not, I've already been using your MXADataModel project as my >> main 'exemplar' CMake-based project. I had read several messages from you in >> the archives when I was first getting started with CMake, and I think at >> least one of them also mentioned MXA, so I went to your website and saw that >> the source was available so I thought I'd take a peek. >>> >>> Anyway, let me clarify a little bit what we're trying to accomplish. We are >> indeed trying to treat ProjectA and ProjectB as completely independent >> projects (as Alan has suggested), and our plan is to version ProjectA and do >> drops at specific milestones. ProjectB will use only the binary distribution >> of ProjectA. We would like to make it so that ProjectB's source tree in >> version control is entirely self-contained, so that we can simply sync down a >> local copy in a fresh development environment and compile without having to >> 'install' ProjectA first. Better yet, we may want to sync multiple copies of >> ProjectB's source tree in separate locations on the same system, from >> different in
Re: [CMake] Best practices/preferred methods for linking external libraries
On Dec 5, 2011, at 5:57 PM, Michael Jackson wrote: > On Dec 5, 2011, at 5:36 PM, Matthew LeRoy wrote: > > > On Dec 4, 2011, at 11:59 AM, Michael Jackson wrote: > > > >> On Dec 1, 2011, at 4:56 PM, Matthew LeRoy wrote: > >> > >>> We began using CMake a few months ago for a couple of small cross- > platform projects, and we're still > >>> learning all the ins and outs and capabilities CMake has to offer, as > well as how to get the most > >>> out of CMake by using it "The Right Way". Right now, we're trying to > figure out how to link > >>> to external libraries that don't have "find" modules or CMake config-mode > files. After lots of > >>> reading in the wiki, mailing list, etc, it seems like there are several > different ways to do > >>> this, like writing "find" modules and/or config-mode files ourselves, > using the LINK_DIRECTORIES() > >>> command, importing/exporting targets, and others. What we're unsure of > is, what is the "preferred" > >>> or "officially supported" method? > >>> > >>> To be a little more specific, we have two different library projects > (call them ProjectA and > >>> ProjectB) that both use CMake, but are developed independently. Further, > ProjectB depends (or will > >>> depend) on ProjectA; we've just recently gotten to the point on ProjectB > where we want to use some > >>> of the functionality in ProjectA, so we need to link to the ProjectA > library(ies). At first we > >>> thought we needed to write a "find" module for ProjectA -- but we really > have very little idea how > >>> to go about doing that. Other than the wiki page for finding libraries > that talks a little about > >>> writing "find" modules > (http://www.vtk.org/Wiki/CMake:How_To_Find_Libraries), is there any other > >>> documentation for writing a proper "find" module? Is there a particular > module that ships with CMake > >>> that is well-written that we should look at as a guide? > >> > >> I had a project that I developed a few years back which was very close to > your situation. My project, call it "MXA", was the base library that got used > in a number of other projects. What I ended up doing was creating a > "FindMXA.cmake" file that got configured during the actual build of MXA to > make sure all the proper library names and location of resource files were > set correctly. Then I would install the MXA project into an external location > on my system, say /Users/Shared/Toolkits (OS X). I would manually copy the > FindMXA.cmake file to the other projects so that they could have the find > module available. In the beginning this made for a lot of manual copying when > MXA was changing a bunch but once MXA settled down to a consistent naming > scheme the "FindMXA.cmake" file never changed and so I found I did not have > to update the "FindMXA.cmake" file in the other projects that depended on > MXA. > >> I think in more recent years the CMake developers would rather see people > create the CMake Export files instead of developing the Find* module for my > project. In the end I just didn't have the time to properly investigate and > implement the CMake Export file so I never did it. > >> > >> I think if the CMake community took a vote we could probably come up with > an "Exemplar" Find*.cmake file that is good for someone trying to develop a > new one. The issues that arise are that each of the projects that have a > "Find*.cmake" file are usually different in subtle ways which leads to issues > when you try to simply "copy/paste" from an existing module to create a new > module. It really just depends on what your "ProjectA" has installed. I am > going to provide my current "FindMXA.cmake" file at the end of this email and > leave it open for criticism/corrections. Maybe it will spur a conversation > that we can all benefit from. > > > > Believe it or not, I've already been using your MXADataModel project as my > main 'exemplar' CMake-based project. I had read several messages from you in > the archives when I was first getting started with CMake, and I think at > least one of them also mentioned MXA, so I went to your website and saw that > the source was available so I thought I'd take a peek. > > > > Anyway, let me clarify a little bit what we're trying to accomplish. We are > indeed trying to treat ProjectA and ProjectB as completely independent > projects (as Alan has suggested), and our plan is to version ProjectA and do > drops at specific milestones. ProjectB will use only the binary distribution > of ProjectA. We would like to make it so that ProjectB's source tree in > version control is entirely self-contained, so that we can simply sync down a > local copy in a fresh development environment and compile without having to > 'install' ProjectA first. Better yet, we may want to sync multiple copies of > ProjectB's source tree in separate locations on the same system, from > different instances in time where the version of ProjectA in use is > different, and be able to build and debug both separate c
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] "make install" files
2011/12/6 H Xu : > Hello, > > In cmake, install command is used to indicate the files that need to be > installed, and install(DIRECTORY ...) could be used to install directories. > However, I can't find a way to install files in a directory EXCEPT a few > files that I do not want to install. Is it possible to do this? May be using the PATTERN option + EXCLUDE see the doc from install(DIRECTORY dirs... DESTINATION [FILE_PERMISSIONS permissions...] [DIRECTORY_PERMISSIONS permissions...] [USE_SOURCE_PERMISSIONS] [OPTIONAL] [CONFIGURATIONS [Debug|Release|...]] [COMPONENT ] [FILES_MATCHING] [[PATTERN | REGEX ] [EXCLUDE] [PERMISSIONS permissions...]] [...]) http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:install -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- 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
[CMake] "make install" files
Hello, In cmake, install command is used to indicate the files that need to be installed, and install(DIRECTORY ...) could be used to install directories. However, I can't find a way to install files in a directory EXCEPT a few files that I do not want to install. Is it possible to do this? Thanks! Hong -- 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 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] Copy a input file from src folder to EXECUTABLE_OUTPUT_PATH
I want to be moved to the same folder as the executables.
How do I do that in CMake?
At configuration time:
CONFIGURE_FILE(//input.txt ${EXECUTABLE_OUTPUT_PATH} COPYONLY)
Note that the destination directory, i.e. the EXECUTABLE_OUTPUT_PATH,
possibly must already exist, and refer to the EXECUTABLE_OUTPUT_PATH
variable only after it has received its value. BTW, this variable is
obsolete, use [CMAKE_]RUNTIME_OUTPUT_DIRECTORY[_] variable/
properties instead.
At build time:
ADD_CUSTOM_TARGET(input ${CMAKE_COMMAND} -E copy_if_different
//input.txt ${EXECUTABLE_OUTPUT_PATH})
ADD_DEPENDENCIES(OneOfYourExecutables input)
ADD_DEPENDENCIES(AnotherExecutable input)
or
ADD_CUSTOM_COMMAND(TARGET OneOfYourExecutables
COMMAND ${CMAKE_COMMAND} -E copy_if_different
//input.txt $)
ADD_CUSTOM_COMMAND(TARGET AnotherExecutable
COMMAND ${CMAKE_COMMAND} -E copy_if_different
//input.txt $)
Personally, I'd prefer the latter as it's clean and quite flexible.
Thanks. Great 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
[CMake] import/export and DLL's
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
