This file seems to not do anything useful. From what I can tell the
OSX_FATLIB option sets CMAKE_OSX_ARCHITECTURES to "x86_64;i386". This
doesn't account for the arm that apple now has, as well as 32 bit
support being completely removed, and I think it's entirely reasonable
to expect users to pass the necessary architectures they want
themselves. It's possible this could break some users who rely on this,
but I sincerely doubt anyone does. The solution is trivial either way
(put -DCMAKE_OSX_ARCHITECTURES="i386;x86_64" on the command line
yourself)
The second part of BuildOptions.cmake claims to set PLATFORM to "Web" if
the emscripten toolchain file is used (if (EMSCRIPTEN)), but it does not
work correctly anyway. Currently, glfw searches for wayland and x11
libraries and fails likeso:
CMake Error at /usr/share/cmake/Modules/FindPkgConfig.cmake:645 (message):
The following required packages were not found:
- wayland-client>=0.2.7
- wayland-cursor>=0.2.7
- wayland-egl>=0.2.7
- xkbcommon>=0.5.0
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindPkgConfig.cmake:873 (_pkg_check_modules_internal)
src/external/glfw/src/CMakeLists.txt:163 (pkg_check_modules)
Considering this code doesn't work as described, it's okay to delete it.
I think a better check should be implemented, but that is for a
different PR.
* Documenting the compiler flags
* Moved some android compiler flags and added documentation on them too.
* Some more restructuring.
Removed unnecessary comments that were self described by the code.
Added some more explanations around certain parts of CMake and especially around compiler flags.
* Delete emscripten.cmake
This file is not needed at this point. EMSDK provides a toolchain file that has a lot more things in it and is better supported. Project currently works fine with the documentation provided in Emscripten SDK on how to build projects.
* First pass file separation.
The main two files are cleaner now. Only important things can be seen. Major changes include:
- raylib_static is now the alias instead of raylib
- Repeating segments are removed and pulled into separate files into <root>/cmake
- File is reordered to make more sense
- Installs are better structured
- Library is build into an output directory "raylib" instead of "src"
- All public header files are now set as a public header file
- Source files need to be listed (it is a bad practice to capture them using wildcards and file globs)
- CMakeLists are better commented
* Second pass on the example dirs.
They are quite complex so I'm more hesitant to do major changes. Also it works pretty well. Noticed that I forgot one of the seperated files and added it into src/CMakeLists.txt.
* Returned the header copy as it was convenient to have the public headers copied.
* A better description to the variable RAYLIB_IS_MAIN
Co-authored-by: Rob Loach <robloach@gmail.com>
* Remove debug message
Co-authored-by: Rob Loach <robloach@gmail.com>
* Improvements based on review.
* Simplify the install condition to not be platform specific as it was before.
Co-authored-by: Alexander Neumann <30894796+Neumann-A@users.noreply.github.com>
* Remove some CMAKE variables as they don't affect the build in any way
Co-authored-by: Alexander Neumann <30894796+Neumann-A@users.noreply.github.com>
Co-authored-by: Rob Loach <robloach@gmail.com>
Co-authored-by: Alexander Neumann <30894796+Neumann-A@users.noreply.github.com>
This change only modifies the default value. In cmake you can have raylib as a subdirectory (dependency) and when you have it as dependency you wouldn't probably want to use the example by default. You can still use the option to enable them though.
* Fixed the build for web using CMake.
I found that the build for me was failing and I added some if defined checks in the core.c file where the glfwSetWindowAttrib was used. (error: implicit declaration of function 'glfwSetWindowAttrib' is invalid in C99 [-Werror,-Wimplicit-function-declaration])
I also changed some values in the toolchain file so that it correctly uses the .bat files when on windows.
* Cleaned up the additional variables (they are not important)
* Added more improvements to cmakelists
Added the option to use the system provided Emscripten toolchain to be more uniform with other libraries.
Fixed and issue which prevented example being built from cmake and also building with html extensions properly.
* Fixed ENUM to STRING because of a missed warning
As noted in #539, the symlink check was to support compiling raylib on
VirtualBox vboxfs as no symlinks are supported there.
With me using Linux as daily driver outside VirtualBox now, this 'feature'
is most likely unused by anyone, but still annoys other users (#791).
Just revert it and be done with it. If there are really others building
raylib on vboxfs or a similarly crippled file system under Linux, they
should now step forward when their build breaks.
This reverts commit b8ca51fd01.
They not only result in discrepancies between different compiler,
but trigger undefined behavior. Avoid them by having them break
the CMake build and CI.
Remove that link_libraries_to_executable() hack and defines a proper
raylib target that can be used with target_link_libraries.
The same target is also available for external (user) code by using
find_package(raylib).
This results in:
- Remove hardcoded build directories from examples and games CMakeLists.txt
- Allow rlgl_standalone and other special examples to be built easily
- Allow CMake projects to find_package(raylib instead of fiddling with pkg-config
- Makes code a little more maintainable
- Fixes#471, #606.
- Makes code less confusing by removing the double use of PLATFORM (#584).
Note that this is still not _The Right Way_(TM), because normally
raylib-config.cmake (or its includes) would be automatically generated.
I didn't manage to get that to work though, so I went the easier route
of just wrapping pkg_check_modules for consumption by find_package.
Panders to the idiosyncrasies of my work flow:
I have my raylib build directory mounted as a VirtualBox vboxfs for use
with my Linux VM, but vboxfs doesn't support symlinks, while raylib shared
library versioning on Unix expects symlinks to work.
If this happens, library versioning is now disabled on Unix with
an error message instead of just failing the build.
jar_xm.h does some shady pointer casts leading to unaligned accesses
and breaking strict aliasing. x86 has special circuitry for doing
unaligned accesses, but on other architectures, it may trap and require
kernel fix-up or crash outright. With this patch, one obstacle in
porting raylib to the GameBoy Advance has been removed. Go for it ;-)
To avoid having to rewrite that `mempool' code, insert padding before
structs and instruct the compiler (GCC, most importantly), to be gentle
when optimizing.
This fixes#490 (Unless we got ourselves 256-bit pointers, if so,
hello future!)
Peter0x44