$prefix/lib isn't in pc_path on Fedora 28:
[root@fedora-28 ~]# pkg-config --variable=pc_path pkg-config
/usr/lib64/pkgconfig:/usr/share/pkgconfig
This has the effect that the pkg-config file is written to the
correct location but pkg-config --libs raylib doesn't output
the correct library path. This fixes this problem by substituting
the directory names into the .pc, same as we do with the CMakeLists.txt
since #518.
This issue popped up during the automated test of the Perl bindings:
https://github.com/athreef/Alien-raylib/issues/3
When capturing framebuffer, if some element with transparency has been drawn, it retrieves that data... it could be a bit annoying in some situations because we could expect color compositing with background color... It depends on the situation and our needs... but most of the time we don't want that transparency on screenshots.
This specific change could be very annoying for people already using FLAG_MSAA_4X_HINT, their programs will compile correctly but window won't be shown...
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.
glfw/glfw@5595fa3ae6 implements a proper fix for the macOS Mojave
problem of OpenGL windows not being rendered until moved or manually
updated.
Pull in the current master and rebase the three patches we have on top:
- two commits we have for reuse of the GLFW CMake build system for Wayland
It hasn't yet to be acknowledged upstream.
- one commit removing #include <windows.h> in glfw3native.h to avoid
duplicate declarations.
Fixes#655 and #665.
Specific textures generation code is quite redundant and not flexible for the user, I'm trying to figure out some easy way to allow raylib users to do the same without needing those functions (very specific and shader dependant). RenderTexture loading and Cubemap textures support must be improved.
CMake defaults to generating a Visual Studio build on Windows,
which doesn't involve make. Thus use cmake --build to abstract
that detail away. We already do that in the appveyor.yml.
The install line is a bit hacky: cmake might not be in the search
path when using sudo, thus use "$(which cmake)" to get the path,
sudo doesn't seem to be available on the Travis CI windows
environment, so use $(which sudo) without quotes to expand to
nothing if that's the case...
