I think your question make sense, I would be interested to know proposed
solutions, as likely have similar problems.
I' m far from being a cmake guru, but I like SuperBuild pattern as well .
I would do these steps:
0) define where are on the different platform the sources of the SDL
library
How did you compile SDL?
Most generally, you would do:
find_path(SDL2_INCLUDE_DIR SDL.h PATH_SUFFIXES SDL2)
# I have no idea against which libraries you have to link, so you might
need more than this
find_library(SDL2_LIBRARY SDL)
if(NOT SDL2_INCLUDE_DIR OR NOT SDL2_LIBRARY)
message(SEND_ERROR
It looks like I'm still asking the wrong questions.
As a last resort, here's my specific problem: I want to compile and run a
hello world SDL2 application on Windows, Linux, and OS X - purely as an
exercise in CMake. How would YOU do this?
SDL2 only exists in source form in their repository.
Thi
On 2/4/2013 8:05 AM, Ansis Māliņš wrote:
Exactly! So, going back to my original question, how do I use CMake in
face of DLL Hell?
Does this help you at all:
http://www.kitware.com/blog/home/post/4
--
Bill Hoffman
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
bill.hoff...@kitware.com
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.
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 al
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 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,
>
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
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 wrote:
> Hi
>
>
> On Mon, Feb 4, 2013 at 1
Hi
On Mon, Feb 4, 2013 at 12:43 PM, Ansis Māliņš 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 fi
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 o
11 matches
Mail list logo
