The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

Dear all,

as discussed elsewhere, there are ideas to create a cmake-based build
system for SDL2. Find my very own attempt for it attached to this mail.

The script is in a state to build static and shared SDL2 libraries on
BSD and Linux systems. The resulting libraries were not tested yet and
the script will be refined over the next days (and weeks).

Apply the patch with

# <cd to SDL2 HG checkout>
# patch -p1 < /location/of/cmake_20120817.diff

Afterwards create an off-source build directory, so we do not clutter the
HG checkout and run cmake:

# <cd to SDL2 HG checkout>
# mkdir build
# cd build
# cmake ..
[cmake output ahead]

Once executed successfully, you are presented with a set of SDL2 compile
and runtime options that were detected, enabled or disabled. The script
closely resembles the configure script logic when detecting SDL2
options.

To enable or disable certain options, provide a -D<OPTION>:BOOL=ON|OFF
flag (below an example for disabling the video subsystem):

# cmake -DVIDEO:BOOL=OFF ..

You can find the supported options near the top of the CMakeLists.txt
file. You also can use the `ccmake` utility for a curses-based interface
that presents you the configurable options or `cmake-gui` for a
GUI-based interface, depending on how it is installed on your OS.

Known issues:

- configure/autotools internally use several defaults that can vary
depending on platforms. Their usefulness will be evaluated and take
into consideration later on
- X11 vidmode and screensaver support detection seems to have a small
glitch, depending on the X11 version and installation - those should
be fixed soon
- dlopen options might behave differently from configure - I could not
find out the intended logic from the configure script (see the TODO
in CMakeLists.txt)
- mprotect check might not work as supposed
[- different option scenarios were not thoroughly tested yet]
- SDL2.pc, SDL2.spec and sdl-config might contain errors
- no installation support yet

If you run into issues with the script or output, please provide the
following information:

- console output
- CMakeFiles/CMakeError.log
- CMakeFiles/CMakeOutput.log
- exact OS version and versions of the installed depdendencies to be used

Note that CMakeFiles/CMakeError.log and CMakeFiles/CMakeOutput.log might
contain sensitive information about the environment. If you are working
in a company with policies limiting/restricting those information, make
sure to strip them from the files beforehand.

Cheers
Marcus

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

It's just a comment, but there's an on going effort in cmake to use a
NON SHOUTING SYNTAX and use lower case for all directives (see the
recent cmake dev discussions about code freeze). It makes for much
nicer cmake files; since this is the direction cmake is going, perhaps
doing that would make sense here?

~
Doug.

On Sat, Aug 18, 2012 at 6:39 AM, Marcus von Appen wrote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Marcus, I'll peek at this tonight when I have some time :)

On Sat, Aug 18, 2012 at 5:12 AM, Doug wrote:

Dear all,

an updated version of the CMake-based build system is available, which
adresses the following issues:

- proper -m machine flag handling for LLVM/CLang compilers
- use libtool-like library versioning
- X11 vidmode and screensaver detection works properly now
- fixed DirectFB detection
- fixed FusionSound detection
- use lower-case directives as suggested by Doug
- [untested] basic installation support

Known issues:

- configure/autotools internally use several defaults that can vary
depending on platforms. Their usefulness will be evaluated and take
into consideration later on
- dlopen options might behave differently from configure - I could not
find out the intended logic from the configure script (see the TODO
in CMakeLists.txt)
- mprotect check might not work as supposed
[- different option scenarios were not thoroughly tested yet]
- SDL2.pc, SDL2.spec and sdl-config might contain errors

You can find the patch at

http://www.sysfault.org/tmp/cmake_20120818.diff

Cheers
Marcus

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

This is very exciting stuff, I can't wait to dig into it!

--ryan.



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Working great for me. I particularly like:

if(${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_BINARY_DIR})
message(FATAL_ERROR "Prevented in-tree built. This is bad practice.")
endif()

Yes, so complete agree~ :)

Couple of other comments:

1) Similarly to lowercase syntax, preferred end*() syntax is no
expression in the closing block. It just make maintaining files easier
(if you have if(XXX && YYY) and endif(XXX && YYY) you have to make two
changes every time you touch the statement; ending with endif() is
better unless you have nasty un-nested if statements with no
indentation).

2) As one of the irritating things about cmake UNIX matches for osx,
so you probably want to put your blocks either as:

if(APPLE)
...
elseif(UNIX)
...
endif()

or

if(UNIX AND NOT APPLE)
...
endif()

3) Also seems you missed the file/cocoa .m files, and the frameworks
to link against.

Patch attached.

~
Doug.


On Sat, Aug 18, 2012 at 9:14 PM, Marcus von Appen wrote:

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Doug:


I find the endif(MEH) close blocks quite helpful for developing the scripts
and finding issues with mismatched if()s on refactoring - even though the
maintenance is a bit higher. The readability suffers from that, though. I
think that once most parts become stable enough, those checks can be removed.


I was unaware of that, thanks.


I did not miss them - I just have no knowledge about them :-). Do you mind to
check, if they are integrated correctly? Right now it seems that e.g. Cocoa
is always linked in, even if the user chooses VIDEO_COCOA=OFF or VIDEO=OFF.
Same for the sound libraries, etc.

I merged your patch and will post an updated version of the scripts later on
today.

Cheers
Marcus


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Dear all,

another updated version of the CMake-based build system is available, which
adresses the following issues:

- several minor fixes
- CFLAGS and LDFLAGS environment flag support
- reduce cmake FindXXX dependencies to a minimum (FindX11.cmake) to
allow custom CFLAGS and LDFLAGS
NOTE: this forces the user to set them to e.g. include /usr/local
properly. For cross-compiling however it is necessary to have enough
flexibility, which FindXXX.cmake usually does not give us
- installation support (including OS-specific SDL_config_XXXX.h files
for now)
- sdl2.pc and sdl2-config files are properly created now
- started with Win32/VS.NET support by incorporating
SDL_config_windows.h into SDL_config.h
- changed subsystem knobs to be prefixed with SDL_ (e.g. SDL_TIMERS
instead of TIMERS) to avoid name clashes (SDL_FILE vs. cmake's FILE)
- improved MacOS X support (from Doug, thanks!)

Known issues:

- configure/autotools internally use several defaults that can vary
depending on platforms. Their usefulness will be evaluated and take
into consideration later on
- dlopen options might behave differently from configure - I could not
find out the intended logic from the configure script (see the TODO
in CMakeLists.txt)
- mprotect check might not work as supposed
[- different option scenarios were not thoroughly tested yet]

You can find the patch at

http://www.sysfault.org/tmp/cmake_20120821.diff

Cheers
Marcus

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Great stuff!

Re: frameworks always linking in --> Ah, hadn't considered that. Yeah,
good point. I'll have a look at it and try to get them only linking if
you build the related component. (Probably as a set of if(HAVE_XXX)
inside the existing if(APPLE) block).

I'm not actually sure if Carbon is even required... I just put it in
there because it was in the automake config.

~
Doug.

On Aug 21, 2012 7:12 PM, wrote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hm, this should do it (patch attached).

There's a bit of weird stuff in there though; the haptic
implementation depends on the joystick implementation, you can't have
one without the other.

There's also no way to link at all without linking against cocoa,
since the file implementation depends on it.

I'm also not quite sure I've got the opengl stuff linking right... but
it seems to work for me.

~
Doug.

On Wed, Aug 22, 2012 at 9:06 AM, Doug wrote:

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Doug:


Thanks! I'll include it asap.


I stumbled across that on Win32, too. It looks like the joystick-specific
parts for haptic are not enclosed in a #if !SDL_JOYSTICK_DISABLED conditional.
Same for SDL_VIDEO and SDL_LOADSO, since all the Win32 IME stuff relies on
LoadObject().

Cheers
Marcus


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Dear all,

just another updated version of the CMake-based build system is
available, which adresses the following issues:

- removed FindX11.cmake dependency for cross-compile environments
- Win32/VS.NET support operational now
- fixed some subsystem depdencies for Mac OS X, Win32 and Unix
platforms by issuing a fatal error, which warns the user about those
- even more improved MacOS X support with proper 3rd party dependency
handling (once more Doug, thanks a lot!)

Known issues:

- dlopen options might behave differently from configure - I could not
find out the intended logic from the configure script (see the TODO
in CMakeLists.txt)
@Ryan, Sam: what's the intended behaviour in configure.in?

- the GCC stack boundary preference adopted from configure.in does not
seem to work on 64-bit platforms (reproducible in both, configure
and cmake) with gcc version 4.2.1 20070831:
...
error: -mpreferred-stack-boundary=2 is not between 4 and 12
...
@Ryan, Sam: would it be safe to set it to 4 or is it targeting
32-bit archs mostly?

- some minor issues with subsystem dependencies remain, which need to
be fixed on the source code level and are valid for every build, be
it configure, VS.NET, cmake or whatever. Patches will go into
Bugzilla within the next days.
- Win32 assembler flags are not aware of any configuration knobs yet,
this needs to be fixed on the source code level. Patches will go into
Bugzilla within the next days.

You can find the patch at

http://www.sysfault.org/tmp/cmake_20120823.diff

From my perspective, about 90 percent are done for Win32 and most
Unix-like platforms, when it comes to building the core
library. According to Doug, most stuff seems to work properly on OS X,
too. Everyone interested in it, please give it a try with your typical
build scenario and let me know, if there are any issues.

The cmake build system coexists in a friendly way with the existing
configure, VisualC or XCode build types. It does not modify any files
that would be modified by them, so you should not run into trouble with
parallel build attempts.

Cheers
Marcus

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Dear all,

another updated version for the CMake-based build system is available,
which adresses the following issues:

- fixed dlopen() detection on several Linux-based systems.
- changed LIBC option default for MinGW/MSSYS-based builds

You can find the patch at

http://www.sysfault.org/tmp/cmake_20120827.diff

So far it has been successfully tested on

- FreeBSD (amd64 & i386)
- Linux (Arch 64-bit, Debian 32-bit, Ubuntu 64-bit)
- Windows XP SP3, 32- and 64-bit, VS.NET 2010
- Windows 7 64-bit, VS.NET 2010, MinGW, Msys

Cheers
Marcus

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

You can add "Linux (Gentoo 64-bit)" to that list. :)

Due to numerous autotools-based blockers (1541, 1587), I recently authored a working CMake-based Gentoo ebuild leveraging your obscenely helpful patch set, Markus. (Obscenely, I tell you!)

My wish list is pretty concise:

• A "CMakeReadme.txt" (or... something) describing conditional options. Manually scrolling through "CMakeLists.txt" is a bit cumbersome. Due to the fatal error prohibiting in-tree builds, "cmake -LAH" (the usual alternative to "./configure --help") bombs out. Perhaps in-tree builds could be conditionally permitted only under options "-LAH"? Also, shouldn't "Prevented in-tree built." be "Prevented in-tree build."?
  
• A new conditional option "SDL_VIDEO_X11_XRENDER." I've noted a few improvements already in "CMakeLists.txt" over "configure.in". This could reasonably be another. "CMakeLists.txt" and "configure.in" both currently force libXrender if installed. Like libXcursor (SDL_VIDEO_X11_XRENDER), libXinerama (SDL_VIDEO_X11_XINERAMA), and so on, libXrender is an optional extension arguably deserving an explicit option. While hardly mission critical, it'd be nice (if only for orthogonality).
  

An applause-worthy job all around. Keep it up!