[CMake] External dependencies and Windows

[Michael Wild]

Leave it to your user. Not your problem. Use find_package() (or
find_library() and find_path()) as appropriate, do your best to deal with
common situations (e.g. Python or Qt having keys in the registry telling
you the installation location), and then trust your user to know what he
does. That's all you can do.


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

> 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/953c2cd9/attachment-0001.htm>