Git Product home page Git Product logo

Comments (12)

mosra avatar mosra commented on April 28, 2024

Thank you very much for the detailed report. I actually don't have access to any machine with OS X, so I might not able to trace or fix the exact issue.

  • You are right, the OpenAL finding routine is part of CMake itself. However it seems that the OpenAL library you found is somehow part of XCode, which explains the horrifically long include path. The official FindOpenAL.cmake tries to find it in /Library/Frameworks, thus I assume there must be some standalone version of OpenAL which is not bundled with XCode.
  • With SDL, isn't it possible that you have SDL 1.2 installed too? It would explain the missing header (SDL_scancode.h is available only in SDL2, in SDL 1.2 it was named SDL_keysym.h) -- it seems that CMake mistakenly found the SDL 1.2 include dir, although it did found SDL2 library properly. Sadly CMake doesn't yet provide a well-tested finding routine for SDL2 in default installation, so I must ship my own (buggy) version with Magnum. Weirdly enough, the finding routine in modules/FindSDL2.cmake seems to be already checking for SDL_scancode.h presence, thus it should in theory work flawlessly.

from magnum.

thomcc avatar thomcc commented on April 28, 2024

There's a version of OpenAL that comes with Mac OS X in /System/Library/Frameworks (none in /Library/Frameworks, for me at least), however it doesn't include the headers. The only way to get the one with the headers as far as I can tell is to use the one in the SDK, and I guess these are located inside Xcode.app, for some reason.

And yes, I do have SDL 1.2 installed, and that's probably what it was trying to use. I just did some investigating and it seems that unless I manually override SDL2_INCLUDE_DIR, it settles on /Library/Frameworks/SDL.framework/Headers, which is the SDL 1.2 header directory (it should be /Library/Frameworks/SDL2.framework/Headers). It does find SDL2_LIBRARY correctly, as /Library/Frameworks/SDL2.framework, so maybe something involving just the include path? Not sure if that helps you, but at least its clear what's happening.

from magnum.

ArEnSc avatar ArEnSc commented on April 28, 2024

I have built the library to attempt to reproduce your issue, there were no issues on my end
I am using osx 10.9
cmake version 2.8.10.2 "darwin ports version"
clang 5.0 5000.2.79 llvm 3.3. svn

I installed the SDL2 framework to /Library/Frameworks/

I am going try installing SDL1.2 and see the result.

from magnum.

ArEnSc avatar ArEnSc commented on April 28, 2024

-- The C compiler identification is Clang 5.0.0
-- The CXX compiler identification is Clang 5.0.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found Corrade: /usr/lib/libCorradeUtility.dylib
-- Found OpenGL: /System/Library/Frameworks/OpenGL.framework
-- LIB_SUFFIX variable is not defined. It will be autodetected now.
-- You can set it manually with -DLIB_SUFFIX= (64 for example)
-- LIB_SUFFIX autodetected as '', libraries will be installed into /Developer/libs/lib
-- Could NOT find SDL2 (missing: SDL2_LIBRARY)
CMake Error at src/Platform/CMakeLists.txt:61 (message):
SDL2 library, required by Sdl2Application, was not found. Set
WITH_SDL2APPLICATION to OFF to skip building it.

This is when I removed SDL2 from framework/Headers.

That does not appear to be the case it does not try and settle SDL.framework/Headers what version of cmake are you running?
EDIT:
It appears that I was wrong. I was trying to rebuild from scratch and ran into this issue.

When SDL.framework and SDL2.framework libraries included in frameworks it causes a build problem.
This build problem causes inconsistent errors to arise.
The resolution is to use SDL2 and remove SDL.framework from /Library/Frameworks.
To solve the build problem, now for the actual cmake script I perhaps we can issue a warning since we are not supporting SDL anyways? thoughts?

To reproduce.
Download SDL.framework and SDL2.framework install in /Library/Frameworks
using the usr prefix as the installation directory.
Build Install Corrade
Generate cmake files,
run make on Magnum
at around 40 Magnum will not build correctly

Scanning dependencies of target MagnumGLLoadGenObjects
[ 1%] Building C object external/OpenGL/GL/CMakeFiles/MagnumGLLoadGenObjects.dir/gl_magnum.c.o
[ 1%] Built target MagnumGLLoadGenObjects
Scanning dependencies of target MagnumObjects
[ 2%] Building CXX object src/CMakeFiles/MagnumObjects.dir/AbstractFramebuffer.cpp.o
[ 3%] Building CXX object src/CMakeFiles/MagnumObjects.dir/AbstractImage.cpp.o
[ 4%] Building CXX object src/CMakeFiles/MagnumObjects.dir/AbstractObject.cpp.o
[ 5%] Building CXX object src/CMakeFiles/MagnumObjects.dir/AbstractTexture.cpp.o
[ 6%] Building CXX object src/CMakeFiles/MagnumObjects.dir/AbstractShaderProgram.cpp.o
[ 6%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Buffer.cpp.o
[ 7%] Building CXX object src/CMakeFiles/MagnumObjects.dir/ColorFormat.cpp.o
[ 8%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Context.cpp.o
[ 9%] Building CXX object src/CMakeFiles/MagnumObjects.dir/DebugMessage.cpp.o
[ 10%] Building CXX object src/CMakeFiles/MagnumObjects.dir/DefaultFramebuffer.cpp.o
[ 11%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Framebuffer.cpp.o
[ 12%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Image.cpp.o
[ 13%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Mesh.cpp.o
[ 14%] Building CXX object src/CMakeFiles/MagnumObjects.dir/MeshView.cpp.o
[ 15%] Building CXX object src/CMakeFiles/MagnumObjects.dir/OpenGL.cpp.o
[ 16%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Query.cpp.o
[ 17%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Renderbuffer.cpp.o
[ 18%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Renderer.cpp.o
[ 18%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Resource.cpp.o
[ 19%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Sampler.cpp.o
[ 20%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Shader.cpp.o
[ 21%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Timeline.cpp.o
[ 22%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Implementation/BufferState.cpp.o
[ 23%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Implementation/DebugState.cpp.o
[ 24%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Implementation/State.cpp.o
[ 25%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Implementation/TextureState.cpp.o
[ 26%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Trade/AbstractImageConverter.cpp.o
[ 27%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Trade/AbstractImporter.cpp.o
[ 28%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Trade/AbstractMaterialData.cpp.o
[ 29%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Trade/MeshData2D.cpp.o
[ 30%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Trade/MeshData3D.cpp.o
[ 31%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Trade/MeshObjectData2D.cpp.o
[ 31%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Trade/MeshObjectData3D.cpp.o
[ 32%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Trade/ObjectData2D.cpp.o
[ 33%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Trade/ObjectData3D.cpp.o
[ 34%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Trade/PhongMaterialData.cpp.o
[ 35%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Trade/SceneData.cpp.o
[ 36%] Building CXX object src/CMakeFiles/MagnumObjects.dir/Trade/TextureData.cpp.o
[ 37%] Building CXX object src/CMakeFiles/MagnumObjects.dir/BufferTexture.cpp.o
[ 38%] Building CXX object src/CMakeFiles/MagnumObjects.dir/BufferImage.cpp.o
[ 38%] Built target MagnumObjects
Scanning dependencies of target MagnumMathObjects
[ 39%] Building CXX object src/CMakeFiles/MagnumMathObjects.dir/Math/Functions.cpp.o
[ 40%] Building CXX object src/CMakeFiles/MagnumMathObjects.dir/Math/instantiation.cpp.o
[ 40%] Built target MagnumMathObjects
Scanning dependencies of target Magnum
Linking CXX shared library libMagnum.dylib
[ 40%] Built target Magnum
Scanning dependencies of target MagnumSdl2Application
[ 41%] Building CXX object src/Platform/CMakeFiles/MagnumSdl2Application.dir/Sdl2Application.cpp.o
In file included from /Users/michaelchung/CodeWorkSpaces/XCodeWorkSpace/Projects/magnum/src/Platform/Sdl2Application.cpp:25:
/Users/michaelchung/CodeWorkSpaces/XCodeWorkSpace/Projects/magnum/src/Platform/Sdl2Application.h:41:10: fatal error: 'SDL_scancode.h' file not found
#include <SDL_scancode.h>
^
1 error generated.
make[2]: *** [src/Platform/CMakeFiles/MagnumSdl2Application.dir/Sdl2Application.cpp.o] Error 1
make[1]: *** [src/Platform/CMakeFiles/MagnumSdl2Application.dir/all] Error 2

Remove SDL.framework builds just fine.

from magnum.

thomcc avatar thomcc commented on April 28, 2024

Fails in the same way for me. Requiring that SDL1.x not be installed on mac isn't a very good solution, if you ask me. Why isn't a qualified path to the SDL2 headers used, e.g. <SDL2/SDL_scancode.h>?

from magnum.

ArEnSc avatar ArEnSc commented on April 28, 2024

Good point let me try that out.

from magnum.

ArEnSc avatar ArEnSc commented on April 28, 2024

Hmm okay so I was looking at the code, I think the library developer did not consider the fact there would be library conflicts since it would be assumed that a developer would be using 2.0 SDL as stated on the main page. I am not sure why SDL 1.2 would be used is there a specific reason? but yeah the cmake script should be fixed to allow provide the direct path to the SDL 2.0 library in case of an issue where two libraries exist.

from magnum.

thomcc avatar thomcc commented on April 28, 2024

I don't have much of a reason for keeping SDL1.x around other than that I have some old projects that depend on it that I'm fond of, but other users might have a more compelling reason to do so. I'd be surprised if there weren't people working on projects that used SDL1, because upgrading to SDL2 is not seamless. Not to mention any of the other reasons people might be required to use outdated libraries (School, work, etc).

Anyway, as I see it, the problem is that the build system fails to detect a configuration error on mac if SDL1.x and SDL2 are both installed. I think the easiest and best solution to this is to modify the build system to allow #include <SDL2/SDL_blah.h> to work on all platforms, and then use that everywhere. I guess you could also detect that SDL1.x is installed an issue an error, but that's pretty weak IMO.

This is assuming there isn't a reason that the fully qualified paths weren't used in the first place, maybe there are other platforms that prevent it (in which case the code will likely need lots of ifdef __APPLE__ and the config files will need to only change the path on mac, which is obviously the worst solution). But my guess is that it was a stylistic choice (path names in include files don't seem to be common in this library).

from magnum.

ArEnSc avatar ArEnSc commented on April 28, 2024

#36

Related.

from magnum.

mosra avatar mosra commented on April 28, 2024

I think the easiest and best solution to this is to modify the build system to allow #include <SDL2/SDL_blah.h> to work on all platforms, and then use that everywhere.
[...]
This is assuming there isn't a reason that the fully qualified paths weren't used in the first place, maybe there are other platforms that prevent it.

This was exactly the reason for using #include <SDL_blah.h> instead of #include <SDL2/SDL_blah.h>. In SDL 1.x times some platforms had <SDL/SDL_blah.h>, some <SDL12/SDL_blah.h>, some <SDL-1.2/SDL_blah.h> etc., so detecting the directory in CMake, adding it to include path and then including only <SDL_blah.h> was the least annoying solution. Thus for me this seemed to be some kind of future-proof solution also for SDL2.

Anyway, the real problem is that the FindSDL2.cmake module isn't able to disambiguate between SDL1 and SDL2. I have an idea for a fix, but can't test it. Could you change the following line https://github.com/mosra/magnum/blob/master/modules/FindSDL2.cmake#L46 to list only SDL_scancode.h (i.e. remove SDL.h) and try clean build again? This should force CMake to find the right path and not mistake it with SDL1 one.

from magnum.

ArEnSc avatar ArEnSc commented on April 28, 2024

It passed the simple tests.

from magnum.

mosra avatar mosra commented on April 28, 2024

Solved with the mentioned fix in pull request #38.

from magnum.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.