Notes |
|
(0032677)
|
Benjamin Eikel
|
2013-03-20 04:16
|
|
Question to other CMake developers: Should these additional paths be added to the SDL find modules or is there a CMake-wide solution (maybe adding them to the standard library search paths)? |
|
|
(0033971)
|
Paul "TBBle" Hampson
|
2013-10-03 23:01
|
|
It's been pointed out to me (but I haven't tested it yet) that doing the following before calling the FindSDL module would function as a workaround, although it is overriding a CMAKE-detected variable and so would need to be reset back afterwards.
IF(CMAKE_GENERATOR MATCHES Win64)
SET(CMAKE_LIBRARY_ARCHITECTURE x64)
ELSE()
SET(CMAKE_LIBRARY_ARCHITECTURE x86)
ENDIF() |
|
|
(0033972)
|
Benjamin Eikel
|
2013-10-04 03:13
|
|
Thank you for your reply. In my opinion, your workaround sounds like there is a problem with the CMAKE_LIBRARY_ARCHITECTURE variable. Maybe it is related to issue 14457 (http://www.cmake.org/Bug/view.php?id=14457 [^]). |
|
|
(0034087)
|
Paul "TBBle" Hampson
|
2013-10-09 20:11
|
|
The problem is that the correct value for "CMAKE_LIBRARY_ARCHITECTURE" on 32-bit Win32 is "x86" for some libraries, and "Win32" for others. For 64-bit Win32, it's normally "x64" although the Visual Studio C++ runtime's folder is "amd64".
A quick survey of my machine: the DirectX SDK and the v7 and v8 Microsoft SDKs use "x86" and "x64", but the Visual-Studio bundled runtime and ATL/MFC libs use "" and "amd64". Python's build system (at least in 2.7) also outputs its libs to "" and "amd64". The v6 Microsoft SDKs use "" and "x64".
Currently both 32-bit and 64-bit are coming up with "" for CMAKE_LIBRARY_ARCHITECTURE, so issue 14457 does affect this, but resolving that probably won't resolve this. I expect resolving issue 14457 for Visual Studio would match the runtime library, giving "" and "amd64" for 32-bit and 64-bit MSVC compiler respectively.
What I'd suggest is that once issue 14457 is resolved for Visual Studio, we can check the value of CMAKE_LIBRARY_ARCHITECTURE in FindSDL.CMake to add the right library PATH_SUFFIXES for the current architecture. So like my current workaround, but without relying on the generator name. |
|
|
(0034092)
|
Paul "TBBle" Hampson
|
2013-10-10 06:23
|
|
Looking at issue 0014457, that's not the issue, that's a bug in code that should work.
A check through the code suggests that right now, neither MSVC nor Clang-simulating-MSVC will have "CMAKE_${lang}_VERBOSE_FLAG" set, and so will not try to populate CMAKE_LIBRARY_ARCHITECTURE.
I wrote up a patch to do that, and submitted it as issue 0014473. If and when this goes it, FindSDL.cmake can mangle CMAKE_LIBRARY_ARCHITECTURE to match the upstream-provided SDK with no extra work and without relying on the generator as I do now.
http://cmake.org/Bug/view.php?id=14473 [^] |
|
|
(0034096)
|
Brad King
|
2013-10-10 08:57
|
|
Issue 0014457 is on a system with hand-built toolchain not configured with the system architecture triplet AFAICT.
The proposal in 0014473 is not a general solution because different packages may not agree on the per-architecture directory name.
The path suffixes approach proposed in the "additional information" is the right approach for FindSDL IMO. |
|
|
(0034097)
|
Brad King
|
2013-10-10 09:00
|
|
|
|
(0034430)
|
Benjamin Eikel
|
2013-11-11 16:33
|
|
|
|
(0034454)
|
Paul "TBBle" Hampson
|
2013-11-17 18:46
|
|
I haven't tested the modules yet, but on brief inspection, SDL_sound probably shouldn't be changed this way as, as far as I can see, there's no current upstream-supplied binary Visual Studio devkit.
The VC6 project files in the source distribution of SDL_sound only produce 32-bit libs, and output into a "VisualC/win32lib" folder. We could probably guess that their 64-bit lib folder would be "VisualC/win64lib" if we want to apply this patch's logic. The headers are in the top-level of the source archive. |
|
|
(0034455)
|
Paul "TBBle" Hampson
|
2013-11-17 20:10
|
|
I've just tested SDL and SDL_image in my local project, both 32-bit and 64-bit, and they appear to be working fine. I checked the directory layout of SDL_ttf, SDL_net and SDL_mixer's VC-devel packages and they match SDL and SDL_image.
So apart from SDL_sound mentioned above, this looks fine to me. |
|
|
(0034474)
|
Benjamin Eikel
|
2013-11-18 15:10
|
|
|
|
(0034507)
|
Benjamin Eikel
|
2013-11-21 14:17
|
|
|
|
(0034508)
|
Brad King
|
2013-11-21 15:31
|
|
|
|
(0036021)
|
Robert Maynard
|
2014-06-02 08:37
|
|
Closing resolved issues that have not been updated in more than 4 months. |
|