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 <[email protected]> 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ņš <[email protected]>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 <[email protected]> wrote: >> >>> Hi >>> >>> >>> On Mon, Feb 4, 2013 at 12:43 PM, Ansis Māliņš <[email protected]>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
