[CMake] External dependencies and Windows

[Andreas Haferburg]

DLL Hell becomes an issue when executing a program. The EXE needs to use the DLLs that correspond to 
the LIB files it was linked against.

I think you're only concerned with building a library or an executable here. The way CMake is 
designed is that you simply call find_package(), and the FindX.cmake script is supposed to figure 
out the rest.

When it comes to building a Windows installer for your EXE, only then will you have to be concerned 
with DLL hell (i.e. add all DLLs to the installer).

Regards,
Andreas



On 04.02.2013 14:05, Ansis Māliņš 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 <mailto: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
>     <mailto: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 <mailto:themiwi at gmail.com>>
>         wrote:
>
>             Hi
>
>
>             On Mon, Feb 4, 2013 at 12:43 PM, Ansis Māliņš <ansis.malins at gmail.com
>             <mailto: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
>
>
>
>
>
>
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>


-- 
Scopis GmbH
Blücherstr. 22
10961 Berlin
Germany

E-Mail: ahaferburg at scopis.com
Tel.: +49 (30) 201 69 38 0
Fax.: +49 (30) 201 69 38 20
Internet: www.scopis.com

HRB 128315 Berlin Charlottenburg
USt-IdNr.: DE272721463
Steuernummer: 29/014/02034
Geschäftsführer:  Bartosz Kosmecki

Diese E-mail, einschließlich der Anhänge, ist ausschließlich für den oben genannten Adressaten 
bestimmt und beinhaltet vertrauliche und/oder gesetzlich geschützte Informationen. Jedem anderen 
Empfänger ist die Vervielfältigung, Weitergabe oder Veröffentlichung untersagt. Falls Sie diese 
Mitteilung irrtümlicherweise erhalten haben, bitten wir um sofortige Information an den Absender und 
Vernichtung der E-mail.

This e-mail, including the attachments, is for the exclusive use of the above-named addresses and 
contains confidential information and/or information protected by law. Any other recipient is 
prohibited from duplicating, passing on to third parties, or publishing this information. If by 
error you are the recipient of this communication please inform the sender immediately and 
permanently delete this e-mail.