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.
-DWITH_SYSTEM_GLFW=ON: Link against system glfw and fail otherwise
-DWITH_SYSTEM_GLFW=OFF: Use embedded rglfw.c
-DWITH_SYSTEM_GLFW=IF_POSSIBLE: Probe for system glfw but fallback to
rglfw if unavailable
Also change Linux 64-bit CI build to install system glfw and use it,
so this doesn't bitrot.
Addresses #453.
Now with external OpenAL and GLFW dependencies removed,
we don't have to worry about installing them in CI.
Shared libraries are now always built along with static libs.
Games and examples are built everwhere except for Visual Studio,
because Physac needs pthreads, which VS doesn't provide.
They were disabled because they failed to build,
but this patch set fixes the build on Linux and macOS.
This doesn't apply to the AppVeyor build on Windows yet;
it currently fails at linking with OpenAL.
... for now.
Syntax was confusing Travis CI, AppVeyor is reporting 401,
so lets see if this change at least fixes Travis.
If this doesn't work, it might be that @raysan5's token is required.
cmake --build . --target package # or make package if make is used
can now be used to create binary packages for raylib.
AppVeyor and Travis CI are configured to push the artifacts
that result from building git tags to the related Github releases page.
After installation, compiling new programs is possible with
$ cc game.c `pkg-config --static --libs --cflags raylib`
or
$ cc game.c `pkg-config --libs --cflags raylib`
depending on configuration
Also adds following configuration options:
- WITH_PIC "Compile static library as position-independent code"
- STATIC_RAYLIB "Build raylib as a static library"
- MACOS_FATLIB "Build fat library for both i386 and x86_64 on macOS"
There have been two problems:
* GLFW itself was compiled with the definitions for compiling
_against_ GLFW (fixed by removing requirement for external glfw)
* rglfw.c was being compiled as C code, although it includes
Objective C files.
This _might_ break the Windows build, needs to be checked.
Fixes#391, but as noted I'd prefer though a separate source directory
and build script for GLFW.
