(0032677)
Benjamin Eikel (developer)
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 (reporter)
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 (developer)
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 (reporter)
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 (reporter)
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 (manager)
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 (manager)
2013-10-10 09:00

Re 0014029:0034096: Oh, and to set path suffixes without relying on the generator name, check the value of CMAKE_SIZEOF_VOID_P:

http://www.cmake.org/cmake/help/v2.8.11/cmake.html#variable:CMAKE_SIZEOF_VOID_P [^]

(0034430)
Benjamin Eikel (developer)
2013-11-11 16:33

I posted a fix proposal [1]. Please, try if it works for you, if it really fixes your issue, and report back. Then, I will merge it into next.

[1] http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=e7e4f05a2a4f3ddeda70493639bb3b0f5b6c573e;hp=13da9f00245694d3dee9f4c9b245f0e3941284c5 [^]

(0034454)
Paul "TBBle" Hampson (reporter)
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 (reporter)
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 (developer)
2013-11-18 15:10

Thanks for the report! I changed the search path for SDL_sound to search for “VisualC/win32lib” [1]. I did not add a search for “win64lib“, because I could not find that string in the VisualC projects of SDL_sound.

[1] http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=057479d3ccaffa7b8423a307554015dbcf23478d [^]

(0034507)
Benjamin Eikel (developer)
2013-11-21 14:17

I merged the changes to next [1]. Thank you again for your fruitful cooperation!

[1] http://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=182974bdb9a7368df3ace0bf5ec2ac0d6abc19bc [^]

(0034508)
Brad King (manager)
2013-11-21 15:31

I squashed the two fixes into:

FindSDL: Add additional search paths on MSVC
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=96197198 [^]

(0036021)
Robert Maynard (manager)
2014-06-02 08:37

Closing resolved issues that have not been updated in more than 4 months.

Notes
(0032677) Benjamin Eikel (developer) 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 (reporter) 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 (developer) 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 (reporter) 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 (reporter) 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 (manager) 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 (manager) 2013-10-10 09:00	Re 0014029:0034096: Oh, and to set path suffixes without relying on the generator name, check the value of CMAKE_SIZEOF_VOID_P: http://www.cmake.org/cmake/help/v2.8.11/cmake.html#variable:CMAKE_SIZEOF_VOID_P [^]

(0034430) Benjamin Eikel (developer) 2013-11-11 16:33	I posted a fix proposal [1]. Please, try if it works for you, if it really fixes your issue, and report back. Then, I will merge it into next. [1] http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=e7e4f05a2a4f3ddeda70493639bb3b0f5b6c573e;hp=13da9f00245694d3dee9f4c9b245f0e3941284c5 [^]

(0034454) Paul "TBBle" Hampson (reporter) 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 (reporter) 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 (developer) 2013-11-18 15:10	Thanks for the report! I changed the search path for SDL_sound to search for “VisualC/win32lib” [1]. I did not add a search for “win64lib“, because I could not find that string in the VisualC projects of SDL_sound. [1] http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=057479d3ccaffa7b8423a307554015dbcf23478d [^]

(0034507) Benjamin Eikel (developer) 2013-11-21 14:17	I merged the changes to next [1]. Thank you again for your fruitful cooperation! [1] http://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=182974bdb9a7368df3ace0bf5ec2ac0d6abc19bc [^]

(0034508) Brad King (manager) 2013-11-21 15:31	I squashed the two fixes into: FindSDL: Add additional search paths on MSVC http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=96197198 [^]

(0036021) Robert Maynard (manager) 2014-06-02 08:37	Closing resolved issues that have not been updated in more than 4 months.

Issue History
Date Modified	Username	Field	Change
2013-03-19 22:34	Paul "TBBle" Hampson	New Issue
2013-03-20 04:16	Benjamin Eikel	Note Added: 0032677
2013-10-03 23:01	Paul "TBBle" Hampson	Note Added: 0033971
2013-10-04 03:13	Benjamin Eikel	Note Added: 0033972
2013-10-09 20:11	Paul "TBBle" Hampson	Note Added: 0034087
2013-10-10 06:23	Paul "TBBle" Hampson	Note Added: 0034092
2013-10-10 06:24	Paul "TBBle" Hampson	Tag Attached: msvc
2013-10-10 08:57	Brad King	Note Added: 0034096
2013-10-10 09:00	Brad King	Note Added: 0034097
2013-11-11 16:33	Benjamin Eikel	Note Added: 0034430
2013-11-17 18:46	Paul "TBBle" Hampson	Note Added: 0034454
2013-11-17 20:10	Paul "TBBle" Hampson	Note Added: 0034455
2013-11-18 15:10	Benjamin Eikel	Note Added: 0034474
2013-11-21 14:17	Benjamin Eikel	Note Added: 0034507
2013-11-21 14:33	Benjamin Eikel	Status	new => resolved
2013-11-21 14:33	Benjamin Eikel	Resolution	open => fixed
2013-11-21 14:33	Benjamin Eikel	Assigned To	=> Benjamin Eikel
2013-11-21 15:31	Brad King	Note Added: 0034508
2014-06-02 08:37	Robert Maynard	Note Added: 0036021
2014-06-02 08:37	Robert Maynard	Status	resolved => closed

Relationships