With v2.5.0 out, increment API_VERSION, so binaries dynamically linked
against the released raylib aren't accidentally paired with a development
or later released raylib that may be incompatible.
Planning to promote raudio module as a simple and easy-to-use front-end for the amazing mini_al library, so the name change.
Name comes from raylib-audio but in spanish it also remembers to word "raudo", meaning "very fast", an analogy that fits perfectly to the usefulness and performance of the library!
Consequently, raylib version has been bumped to 2.4-dev.
The GLFW tree distributed with raylib has two modifications:
- GLFW_PKG_{DEPS,LIBS} are exported to PARENT_SCOPE, so we can use them
in our pkg-config file
- An intermediary glfw_objlib target is added, so we can reexport GLFW
symbols from libraylib.a
rglfw can fix the second point, but for Wayland usage, we would have to
replicate protocol generation, so we just leverage GLFW's existing
support instead.
To make maintenance easier, I have submitted a pull request for
including these modifications to upstream GLFW.
And to make that one easier, this patch dog-foods the modifications,
so raylib users can help find regressions. :-)
glfw/glfw#1307
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.
if (${PLATFORM} MATCHES "Desktop")
target_link_libraries(${RAYLIB}_shared glfw ${GLFW_LIBRARIES})
was never true because PLATFORM STREQUAL "PLATFORM_DESKTOP"...
This fixes#551 and makes the changes suggested in #552 (commited as 965cc8ab)
unnecessary.
This reverts commit 2d6fb5c628,
and adds a fix for Alien::raylib's test failures.
The tests failed because the resulting static library didn't reexport
GLFW symbols. As a fix, we now have GLFW create a CMake "object library"
target that we can link with both the static and shared raylib.
This is arguably ugly... Proper fix would probably be a GLFW upstream
object library target.
Closes#536.
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.
They were named so for compatibility with make, but make doesn't use
the anymore. I always forget whether it's SHARED_RAYLIB or
RAYLIB_SHARED...
For now, RAYLIB_SHARED and STATIC_RAYLIB may still be used,
but print a deprecation warning.
