[CMake] Visual C++ and cpack

[Michael Jackson]

On Jun 1, 2011, at 11:08 AM, Mathias Bavay wrote:

> On 06/01/2011 12:37 PM, Michael Jackson wrote:
>>  If that really is your exact code from cmake you are building a
>> static library only. There must be another argument to the add_library
>> command that says SHARED.
> 
> In a subdirectory (after searching for "SHARED" in all my CMakeLists), I have OPTION( BUILD_SHARED_LIBS "Set to OFF to build static libraries" ON ). So, I guess this happens to activate dynamic libraries. But this means that I should have it on the toplevel CMakeList instead?

From the "ADD_LIBRARY()" Command help is the following:

"If no type is given explicitly the type is STATIC or SHARED based on whether the current value of the variable BUILD_SHARED_LIBS is true." which I actually did not know until right now. So you _are_ doing this one of the correct ways. Some projects do this type of thing slightly differently but ultimately have the same results.

> 
>>   Also Visual Studio will generate the "Release" subdirectory for you.
>> I do not think you can change that behavior.
> 
> But how does cmake handle this? I mean, the path to the build files is then different from the requested path, so how can cpack know where to look for the files to package?

CPack can generally figure these things out. Just FYI if you are building an application for distribution you DO NOT need the .lib files that VS produces. Those are just for linking. IF however you are creating a "Developer" distribution of your application then it is correct to include these files.

  Not sure how correct this is but I have the following for my own project that creates plugins:

    if (NOT APPLE)
        set (BUILD_TYPES "Debug;Release")
        foreach(btype ${BUILD_TYPES})
            INSTALL(TARGETS ${targetName}
                    DESTINATION ./plugins
                    CONFIGURATIONS ${btype}
                    COMPONENT Applications)
        endforeach()
    endif()

The case for Apple OS X is handled differently in my case. (That code may no longer be needed. I just have not checked with CMake 2.8.4 and BundleUtilities lately to find out)

> 
>>  Lastly you may want to consider naming the plugins with a .plugin
>> extension so the cpack rules know the difference between a shared
>> library and a tripe plugin base in file extension which tends to work
>> better in my experience.
> 
> So simple and so obvious... I should have thought about it, thanks!
> 
> Mathias

Mike Jackson