[CMake] External dependencies and Windows

[Ansis Māliņš]

Exactly! So, going back to my original question, how do I use CMake in face
of DLL Hell?


On Mon, Feb 4, 2013 at 2:58 PM, Michael Wild <themiwi at gmail.com> wrote:

> 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/bb2eb5aa/attachment.htm>