[CMake] Do not build/install import library

Michael Hertling mhertling at online.de
Fri Nov 25 08:24:24 EST 2011


On 11/25/2011 10:22 AM, Matthias Gehre wrote:
> 2011/11/25 Michael Hertling <mhertling at online.de>:
>> On 11/24/2011 07:53 PM, Mathias Gaunard wrote:
>>> On 11/23/2011 10:14 PM, Matthias Gehre wrote:
>>>> Hi,
>>>>
>>>> thanks for this very nice cmake. I switched just recently to get
>>>> lightspark (lightspark.github.com)
>>>> crossplatform, and it worked really smooth.
>>>>
>>>> One question, though: I cannot seem to find a way to _not_
>>>> build/install the import libraries (foobar.dll.a) on win32.
>>>> I do not need them, because I'm using MinGW's direct linking feature.
>>>> All I found was ways to
>>>> rename it, but not to keep it from building.
>>>
>>> Use the MODULE type of library
>>
>> CMake does not allow to link against a library of type MODULE.
>>
>> ATM, I don't know if one can prevent the import libraries from being
>> built without modifying the platform files or rewriting the affected
>> rule variables; it seems as if --out-implib is present anywhere. In
>> order to prevent them from being installed, it should be sufficient
>> to drop the ARCHIVE DESTINATION clause from the INSTALL() command
>> for the concerned targets.
>>
> 
> Thanks!
> I'm now using the following snippet to install the *.so on linux and just the
> dll on win32. Looks a bit hackish, though.
> 
> ADD_LIBRARY(spark SHARED ${LIBSPARK_SOURCES})
> ...
> #We have to use LIBRARY on linux, but that installs the import library on win32

No, the .so is indeed a LIBRARY on *nix, but the .dll is a RUNTIME on
Windows, and the import library is an ARCHIVE, so it's sufficient to
just drop the ARCHIVE DESTINATION to prevent the latter from being
installed.

> IF(WIN32)
>   INSTALL(TARGETS spark RUNTIME DESTINATION ${PRIVATELIBDIR})
> ELSE()
>   INSTALL(TARGETS spark LIBRARY DESTINATION ${PRIVATELIBDIR})
> ENDIF()

Try

INSTALL(TARGETS spark
    RUNTIME DESTINATION ...
    LIBRARY DESTINATION ...
)

without an ARCHIVE DESTINATION; it's less hackish and should work, too.

Regards,

Michael


More information about the CMake mailing list