[CMake] External dependencies and Windows

Michael Wild themiwi at gmail.com
Mon Feb 4 07:58:51 EST 2013


That has nothing to do whether the libraries are shared (i.e. dynamically
linked) or not. It has to do with the way that packaging works (or rather,
doesn't work) on Windows. In the pre-.NET era it was simply impossible to
use library versioning on Windows. If package A installed python.dll
version X.Y into C:\Windows\System32 and later package B installed version
Z.F into the same place, package A stopped working. Further, packagers
where essentially forced to include all dependencies in their packages
because there's no dependency-resolution mechanism. That's why people
started providing a copy of all the dependencies in the installation
directory of their package. Of course, this leads to a lot of duplication,
especially for rather popular things such as Python or Qt. The whole
situation is referred to as "DLL hell":
http://en.wikipedia.org/wiki/DLL_Hell

Michael


On Mon, Feb 4, 2013 at 1:43 PM, Ansis Māliņš <ansis.malins at gmail.com> wrote:

> If shared libraries on Windows are truly shared, then why so many
> applications carry their own copies of that same Qt and Python? Examples
> from my own Program Files: Anki, Blender, Mixxx, Mumble, TortoiseHg.
>
>
> On Mon, Feb 4, 2013 at 2:15 PM, Michael Wild <themiwi at gmail.com> wrote:
>
>> Hi
>>
>>
>> On Mon, Feb 4, 2013 at 12:43 PM, Ansis Māliņš <ansis.malins at gmail.com>wrote:
>>
>>> I'm just learning CMake and posting questions in this mailing list, but
>>> the answers I get only confuse me. It seems I must take a step back and ask
>>> more general questions.
>>>
>>> In Linux there is a package for everything, so you just find_package
>>> whatever you need.
>>>
>>> But on Windows most libraries exist only as zip files that you're
>>> supposed to unpack right in your build environment and ship them together
>>> with the executable. (Basically, in practice, there is no such thing as
>>> shared libraries in Windows - nothing for find_package to find.)
>>>
>>
>> What then are DLL's? They are the shared libraries of the Windows world.
>> True, the semantics are a bit different, but they are dynamically linked.
>> It's also not true that on Windows everything is a "zip files that you're
>> supposed to unpack right in your build environment". If you don't believe
>> me, try to take a look at Qt or Python.
>>
>>
>>>
>>> So how am I supposed to write portable CMake scripts in face of this?
>>>
>>
>>
>>  Often the Windows packages are installed into a few well known
>> locations, or even better, create a registry key containing installation
>> information which you then can use to find the software in your CMake code.
>> Also, for SDL I would recommend to use the FindSDL.cmake module (not sure
>> whether that works with SDL2, though), and only if that fails, to resort to
>> ExternalProject. It is good practice to offer the user the choice which way
>> should be used through a cached variable.
>>
>> HTH
>>
>> Michael
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20130204/493c69cd/attachment.htm>


More information about the CMake mailing list