* 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.

CMake relied on this file for configurations and also was interfering in the regular config.h by having a separate definition if building with CMake. This was not entirely correct so instead we will define compile time definitions separately through CMake (CompileDefinitions.cmake) and also will use the provided EXTERNAL_CONFIG_FLAGS that I found that will not use config.h in through the build process.

I also introduced a new compiler option (CUSTOMIZE_BUILD) that when OFF will use the default config.h and when ON will show other options for redefining your own options.

Fixed an error in rlgl.h where if you have both RLGL_STANDALONE and SUPPORT_VR_SIMULATOR you get a compile time error.

This test file is just testing compilation with the library works correctly but is no longer needed because:
- it is not cross platform
- it taps into the CTest system which is better suited for real unit/integration tests
- it can be incorporated into the pipeline of github actions instead in the future

As described in the official documentation https://cmake.org/cmake/help/v3.0/variable/BUILD_SHARED_LIBS.html this flag is global by default and controls if the library will be built as a shared or a static library allowing us to define only one call to the add_library function (without specifying its type). It is also added as an option to be visible in CMake GUI applications.

* Better ignore support for idea projects.

Added a wildcard at the end because different configurations would have a diffeerent build directory.

* Removed external from being a relative include directory for target raylib.

Fixes #1533

* 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>

* Changed extension for web from .bc to .a

I did this to support vcpkg expectation. When using the library from vcpkg for web you would install it using vcpkg install raylib:wasm32-emscripten but also vcpkg expects the output lib to be with .a extension instead of .bc

Doesn't make a difference for standalone builds or when raylib is used as a subdirectory dependency.

* Added headers to install targets to fix vcpkg usage

Currently vcpkg works by installing the cmake target into its packages directory. The problem is that install only copies the public header at this point so we need to add the others to the install targets.

I did this to support vcpkg expectation. When using the library from vcpkg for web you would install it using vcpkg install raylib:wasm32-emscripten but also vcpkg expects the output lib to be with .a extension instead of .bc

Doesn't make a difference for standalone builds or when raylib is used as a subdirectory dependency.

* updated README.md

* fixed CMakeLists.txt to allow building and debugging with Visual Studio Code and CMAKE Tools extension

* added PLATFORM_DRM
contains mouse pointer code from https://github.com/chriscamacho

* removed redundant cleanup in InitGraphicsDevice

* fixed DRM connector mode selection

* added choosen DRM connected mode to log output

* added respecting TargetFPS on DRM mode selection, default to 60

* added support for GetMonitorRefreshRate

* changed SUPPORT_MOUSE_CURSOR_RPI to SUPPORT_MOUSE_CURSOR_NATIVE

* changed avoidProgressive to allowInterlaced

* cleanup, function extraction and improved mode selection

* README reverted to original for PR

* line endings fixed for core.c

* removed old code

* mouse pointer reverted to small square

* replaced SetGraphicDeviceName() by DEFAULT_GRAPHIC_DEVICE_DRM

Co-authored-by: kernelkinetic <kernelkinetic@outlook.com>

Fixes #1380: incorrect usage of CMake paths which causes issues
on some more complicated environments (NixOS especially).

There are no *.lib files that could overwrite each other when building
both static and shared versions of raylib at once. So just use the
normal library name without _static suffix.

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.

We might want to customize this in feature for multi-config builds (e.g.
a Visual studio build with both Debug and Release configurations).

Output the variable value for user awareness.

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.

Fixes: e0e2346c22 ("NO SUPPORT_BUSY_WAIT_LOOP by default")

This fixes the current CI failure.

Renamed flags for convenience.

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.

OPENGL_VERSION is the version requested by the user,
not the detected one...

Fixes #660.

A single warning at configuration time is enough.

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

So user code can use add_subdirectory to build it (similar to what we do
with GLFW or what the projects/CMake/CMakeLists.txt can do).

The CMakeLists.txt checks for an installed raylib and downloads and
installs one if none is found. Afterwards, it builds core_basic_window.c

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.

pkg-config --libs --static raylib and pkg-config --libs raylib
should give the same result if there is no shared raylib installed.

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.

Fixes: e1e036a6 ("Disable glfw only when it is not found and not external", #558)

Did this ever work? Surely, doesn't look like it...