| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
- To support ASYNCIFY instead of EMTERPRETER
- No need to generate a standalone toolchain for Android NDK
|
|
|
|
extra-cmake-modules 5.38.0a is no longer hosted at the specified
kernel.org link. Use the occasion to move on to 5.58.
Because newer ECM debian packages have the control.tar file
xz-compressed, we need to update dpkg as well on trusty.
For more information, see
https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1730627
|
|
CI is failing because we still test with GLFW 3.2, while
the internal GLFW is 3.3. To avoid such breakages in future,
build and install our own GLFW instead of relying on an external
Debian package.
|
|
Move away from v1.12 as GLFW now requires >= 1.15.
|
|
The .travis.yml is getting increasingly ugly. We should maybe consider
creating separate shell scripts for each target..
|
|
|
|
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...
|
|
This reverts commit 214aa0c1b0d5c766d22bbb1069ecfb3a78373577.
|
|
|
|
|
|
|
|
|
|
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.
|
|
also makes one configuration shared-only
dr_flac is not built on i386, because GCC 4.8 complains about asm("cpuid"
clobbering ebx, as it's using ebx for PIC.
Instead of downloading a newer GCC (and multilib),
disable FLAC for that one configuration...
|
|
|
|
|
|
Fixes: 1d0ba96 ("Add GLFW-installed-but-using-our-GLFW-anyway configuration")
|
|
|
|
|
|
|
|
Did this ever work? Surely, doesn't look like it...
|
|
src/core.c does explicitly skip including <camera.h> on Android
and tests fail. Therefore skip these failing tests.
Closes #507.
|
|
Not sure if this ever worked, but now it at least compiles.
|
|
This reverts commit 2d6fb5c628068757387525e190c3afdbe33ae9c6,
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.
|
|
This reverts commit 0adb4b67de6dfe3f7a0a557130dffc3b8f4d6a43,
because it failed tests for Alien::raylib:
http://www.cpantesters.org/distro/A/Alien-raylib.html
|
|
|
|
|
|
Makes it easier to support Wayland later on.
|
|
See #443 for more information.
|
|
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.
|
|
While nice to test, this would mean that the tagged release will depend
on GLFW as well… Therefore disable it for now.
|
|
for consistency with Makefile. Requested by @raysan5 in #453.
|
|
-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.
|
|
|
|
Noted by @eserte in athreef/Alien-raylib#2. Thanks!
|
|
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.
|
|
|
|
Otherwise using a compiler that defaults to -std=c89 or -std=gnu89 will
fail. Example:
http://www.cpantesters.org/cpan/report/abb85066-d283-11e7-9926-b2f4efb9c382
Apparently, -m32 Travis CI build was broken: -m32 was overridden by
-std=gnu99. This fixes that.
|
|
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.
|
|
Forgot that one the first time round, which created some unnecssary
releases.
|
|
... 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.
|
|
|
|
|
|
Also adds commented-out deployment on tag specification
(push build artifacts to Github releases page).
|
