Commit graph

9 commits

Author SHA1 Message Date
Ryan C. Gordon 25e3a1ec90 vulkan: Initial Vulkan support!
This work was done by Jacob Lifshay and Mark Callow; I'm just merging it
into revision control.
2017-08-27 22:15:57 -04:00
Sam Lantinga 1da2c1bb36 Fixed bug 2360 - Wrong -rpath setting includes DESTDIR rather that only the libdir
Marcus von Appen

The LT_LDFLAGS in Makefile.in contain the $(DESTDIR) in -rpath, which instructs libtool to take a wrong path into account for linking.

The issue arises, if DESTDIR is passed at build time and installation time.
-rpath only should use $(libdir) for both SDL 1.2 and SDL 2.x.
2017-08-14 14:10:48 -07:00
Sam Lantinga e4124ff56d Fixed bug 3208 - Minor improvements to the configure script
Rafal Muzylo

"if we're already using libtool, why aren't we using it ?"; they've been inspired by the fact, that at that mark, neither libSDL2_test.a nor libSDL2main.a were being built correctly (not sure if it's fully broken or just because I've tested the out-of-tree build)
2017-08-12 15:00:33 -07:00
Sam Lantinga 496337b3cf Fixed bug 3651 - CMake build does not install CMake package configuration
tschwinger@elitemail.org

Most ironically, although autoconf/automake-based builds install (pretty half-assed) CMake package configuration files, they're missing in installations resulting from CMake-based builds entirely.

A proper configuration file typically also loads target exports (implemented in patch 3572, also fixing this issue - see my comment on that issue for details).

I believe it would be best to let the dinosaurs go extinct and redirect all build efforts to the CMake end for two reasons:

1. It potentially provides the best user experience, but you'd have to give it some love and ship with less quirky buildfiles.

2. It would force distros to build SDL via CMake and thus would ensure target exports are actually available everywhere.

Various CMake patches I submitted today in summary (directly converted from the HG commits and `am`d onto a fork of a git mirror that happened to be on `tip`).

    https://github.com/tschw/SDL/commits/patched

Fixing #2576 #3572, #3613, and this fresh ticket, which is almost entirely advertisement ;).

These already do to make SDL much less of a quirky fella to have in your dependency tree...
2017-08-09 19:03:10 -07:00
Sam Lantinga 53d4f5c9fc Fixed bug 3733 - Makefile sleeps for 3 seconds if configure is out of date 2017-08-09 16:20:04 -07:00
Jonas ?dahl 19d3500ae1 wayland: Build own version of core protocol
Since we are loading shared objects dynamically, build our own version of the
core protocol symbols, so that we in the future can include protocol
extensions.
2016-06-23 18:39:05 +08:00
Philipp Wiesemann f9d8c59a6f Added missing file to the release archive. 2015-07-02 20:11:40 +02:00
Sam Lantinga bf9bd59c01 Fixed bug 2464 - Configure a sdl2-config.cmake.in together with sdl2.pc.in
Leonardo

Despite having a CMakeLists.txt file, SDL2 seems to be mainly built using the autotools system by package-managers. It is nice to have it but it is only useful if you are building SDL2 by yourself.

People that want to use CMake to find their already-installed SDL2 are using a FindSDL2.cmake module based on the old FindSDL.cmake. This is not deprecated but it is discouraged by the CMake devs (see http://www.cmake.org/Bug/view.php?id=14826), as these modules needs maintainers to be included in the official CMake installation.

To fix that, SDL and its accompanying libraries could configure a simple sdl2-config.cmake file, much like it does with sdl2.pc.in. We don't need to configure a full sdl2-config.cmake as in this post, http://forums.libsdl.org/viewtopic.php?t=10068&sid=ccf8abbf0d73fb03ae9cded991e60959 (because it depends on it being built with CMake). Using something as simple as http://www.cmake.org/Wiki/CMake/Tutorials/Packaging#Package_Configuration_Files is deemed enough. Here is another: http://quickgit.kde.org/?p=prison.git&a=blob&f=lib%2Fprison%2FPrisonConfig.cmake.in
2015-06-29 22:24:00 -07:00
Philipp Wiesemann 0e45984fa0 Fixed crash if initialization of EGL failed but was tried again later.
The internal function SDL_EGL_LoadLibrary() did not delete and remove a mostly
uninitialized data structure if loading the library first failed. A later try to
use EGL then skipped initialization and assumed it was previously successful
because the data structure now already existed. This led to at least one crash
in the internal function SDL_EGL_ChooseConfig() because a NULL pointer was
dereferenced to make a call to eglBindAPI().
2015-06-21 17:33:46 +02:00