SDL2 Moving to CMake?

I like Ulrich’s suggestion of using CMake internally, so we’re consistently
getting updated project files, and it doesn’t add an extra step to anyone
who uses one of the pre-build projects/setups (such as gnu make, msvc, and
xcode) - anyone outside of that realm is almost certainly used to taking
one extra step to generate the necessary files, and probably wouldn’t be a
problem.

Laura, I haven’t tried building CMake from source, but presuming you’re on
windows, it’s not necessary to do so - just tell CMake which compilers you
are targetting and it will produce cygwin or mingw makefiles. Otherwise,
if you haven’t heard back from the CMake mailing list, I can give compiling
it from source a go and see if I get any success.On Wed, Aug 15, 2012 at 12:14 PM, LM wrote:

Kai Sterker wrote:

Another option would be to use pkgconfig, although not quite sure how
this will perform on non-Unixish environments:

If you’re referring to pkg-config:
http://www.freedesktop.org/wiki/Software/pkg-config/
There’s a port to Windows. There are also two versions that avoid the
circular glib dependency:
http://sourceforge.net/projects/pkgconfiglite/
https://github.com/nenolod/pkgconf
I’m using pkgconf as a pkg-config replacement on Windows (mingw and
Cygwin) and FreeBSD now. Not having any issues.

If anyone’s interested, I have a list of other options to make that
may work on Windows at:
http://www.mingw.org/wiki/Community_Supplied_Links
in the section labeled Build Utilities - Building
If anyone recommends some other tools to add to the list, please let me
know.

Mason Wheeler wrote:

Right now, SDL is distributed with project files for popular compilers.?
This means that anyone with one of those compilers can pull the source
code
and compile right away.? Throw a dependency on a complicated tool that
they’ve never heard of into the mix before they can even start compiling
anything, and you’ve added a significant barrier to entry.

I agree strongly with this assessment. I can build SDL with no serious
issues
on all the systems I mentioned above. If I were required to use cmake
only to build SDL,
I would have issues building on mingw and possibly Cygwin. (Still
waiting to hear
back if anyone from the cmake list has any ideas why I can’t build
cmake from source
on mingw. If anyone on this list has been able to build it from
source within msys,
please let me know the steps you took to do so.)

As an example, FLTK comes with configure/make files and cmake files.
It’s more maintenance,
but it gives developers more choices. It’s also useful because FLTK
will build successfully
using cmake with the OpenWatcom compiler and there are some issues with
using
configure/make with that compiler and FLTK. Possibly a useful
solution for SDL is to have
multiple ways to build it including gnu style configure/make as long as
those
techniques/scripts/files are currently supported and work for a
platform SDL is used on.

Sincerely,
Laura


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I agree strongly with this assessment. I can build SDL with no serious
issues on all the systems I mentioned above. If I were required to use
cmake only to build SDL, I would have issues building on mingw and possibly
Cygwin. (Still waiting to hear back if anyone from the cmake list has any
ideas why I can’t build cmake from source on mingw. If anyone on this list
has been able to build it from source within msys, please let me know the
steps you took to do so.)

Is there a particular reason you can’t use the windows binaries that are
available through the CMake web site?

I use those in conjunction with MingW32 quite frequently, with nary an
issue.

-DanOn Wed, Aug 15, 2012 at 9:14 AM, LM wrote:

I like Ulrich’s suggestion of using CMake internally, so we’re
consistently getting updated project files, and it doesn’t add an extra
step to anyone who uses one of the pre-build projects/setups (such as gnu
make, msvc, and xcode) - anyone outside of that realm is almost certainly
used to taking one extra step to generate the necessary files, and probably
wouldn’t be a problem.

Indeed, and it could be added as an automated build step when generating
distribution packages.

-DanOn Wed, Aug 15, 2012 at 9:26 AM, Alex Barry <alex.barry at gmail.com> wrote:

I like Ulrich’s suggestion of using CMake internally, so we’re consistently getting updated project files, and it doesn’t add an extra step to anyone who uses one of the pre-build projects/setups (such as gnu make, msvc, and xcode) - anyone outside of that realm is almost certainly used to taking one extra step to generate the necessary files, and probably wouldn’t be a problem.

Indeed, and it could be added as an automated build step when generating distribution packages.

This is a typical must and use case and I start to wonder, if the people here still confuse cmake with a build tool.

Cheers
MarcusOn 15.08.2012, at 19:27, Daniel Leslie wrote:

On Wed, Aug 15, 2012 at 9:26 AM, Alex Barry <alex.barry at gmail.com> wrote:

Kai Sterker wrote:

Another option would be to use pkgconfig, although not quite sure how
this will perform on non-Unixish environments:

If you’re referring to pkg-config:
http://www.freedesktop.org/wiki/Software/pkg-config/
There’s a port to Windows. There are also two versions that avoid the
circular glib dependency:
http://sourceforge.net/projects/pkgconfiglite/
https://github.com/nenolod/pkgconf
I’m using pkgconf as a pkg-config replacement on Windows (mingw and
Cygwin) and FreeBSD now. Not having any issues.

If anyone’s interested, I have a list of other options to make that
may work on Windows at:
http://www.mingw.org/wiki/Community_Supplied_Links
in the section labeled Build Utilities - Building
If anyone recommends some other tools to add to the list, please let me know.

Mason Wheeler wrote:

Right now, SDL is distributed with project files for popular compilers.?
This means that anyone with one of those compilers can pull the source code
and compile right away.? Throw a dependency on a complicated tool that
they’ve never heard of into the mix before they can even start compiling
anything, and you’ve added a significant barrier to entry.

I agree strongly with this assessment. I can build SDL with no serious issues
on all the systems I mentioned above. If I were required to use cmake
only to build SDL,
I would have issues building on mingw and possibly Cygwin. (Still
waiting to hear
back if anyone from the cmake list has any ideas why I can’t build
cmake from source
on mingw. If anyone on this list has been able to build it from
source within msys,
please let me know the steps you took to do so.)

As an example, FLTK comes with configure/make files and cmake files.
It’s more maintenance,
but it gives developers more choices. It’s also useful because FLTK
will build successfully
using cmake with the OpenWatcom compiler and there are some issues with using
configure/make with that compiler and FLTK. Possibly a useful
solution for SDL is to have
multiple ways to build it including gnu style configure/make as long as those
techniques/scripts/files are currently supported and work for a
platform SDL is used on.

Once more: cmake can generate matching build files, which can be bundled either in an upstream distfile or by the package maintainers of $platform.

FLTK, blender and other libs and appa show continuously that providing different solutions in parallel does not work. Check blender’s cmake, scons and make solutions, which differ greatly in behaviour and features for a prominent example of how not to do it :-).

Cheers
MarcusOn 15.08.2012, at 18:14, LM wrote:

I’m not confusing it with a build tool.? How did you get that from what I wrote?

I’m well aware of what CMake is: it’s a pre-build tool that generates the project file for your actual build system.?________________________________
From: “mva at sysfault.org
To: Mason Wheeler <@Mason_Wheeler>; SDL Development List
Sent: Wednesday, August 15, 2012 7:25 AM
Subject: Re: [SDL] SDL2 Moving to CMake?

Mason Wheeler <@Mason_Wheeler>:

One obvious objection comes to mind: As we have so clearly seen, some people don’t even know what CMake is, let alone how to use it.

Right now, SDL is distributed with project files for popular compilers.? This means that anyone with one of those compilers can pull the source code and compile right away.? Throw a dependency on a complicated tool that they’ve never heard of into the mix before they can even start compiling anything, and you’ve added a significant barrier to entry.

Please do not confuse Cmake with a build system. The autotools are not a build
system either, but provide a handy set of scripts for building, once you
executed them - they are (in their purpose) the SAME as CMake.
CMake has the advantage that it not only can deal with GNU-alikes, but Win32,
OSX and whatsnot.

If you are distributing the release tarball, the end user should (and will)
find all related files for building SDL (e.g. a VS.NET solution, Makefile,
XCode project files, etc.) just as he wishes.

Even more, if he has his own $FANC_BUILD_TOOL and it is supported by CMake, he
can simply rerun CMake (here the knowledge gap you mention) would step in) for
his purposes.

The management of all those build-related files however can be centralized
with Cmake, reducing the maintenance efforts and out-of-sync problems.

Long story short:

  • no new tools for end users
  • new capabilities for developers, porters, etc.
  • less maintenance for target platform build systems

Cheers
Marcus

Another option would be to use pkgconfig, although not quite sure how
this will perform on non-Unixish environments:

If you’re referring to pkg-config:
http://www.freedesktop.org/wiki/Software/pkg-config/
There’s a port to Windows.

Just to clarify, I specifically suggested the use of CMake’s
PKGCONFIG_FOUND / PKGCONFIG macros to compensate for a missing
FIND_SDL2 macro. I personally use this on Linux, OSX and MSys, but I
guess it will be less ideal on a pure MSVC development environment.

More on topic, the whole situation with the FIND_package macros in
CMake is my biggest gripe. Each of those is written differently, they
all search in different locations and those in different orders,
sometimes don’t care about case-sensitivity, etc. For example I never
got it to find SDL_Mixer under my MSys build environment. Always had
to edit CMakeCache.txt by hand to get past the cmake invocation. The
makefiles it generated worked flawless, though. Much nicer than what
autotools do. Not so much thrilled by the XCode and Eclipse projects
it generated, however. Pretty messy.

Personally, I don’t care if SDL switches to CMake or not. I believe
CMake to be more widely used than other such tools and less broken.
(Anyone tried building GTK+ on OSX lately, installing to a prefix that
requires root privileges?)

My own project offers both CMake and autotools, as each has their pros
and cons. I find autotools “make dist” behavior way superior, but
getting it to build DLLs on windows was a nightmare. CMake is also
much, much faster, both the cmake step vs. configure and compilation
using the cmake generated makefiles vs. the automake ones.

Whatever the decision, I would recommend to take it all the way,
however. It’s still a lot of work to tend to two different build
systems for a large number of different OSes.

Kai

P.S: I only worked with CMake 2.4 and 2.6, so not sure if some of the
issues noted above are gone with recent 2.8.On Wed, Aug 15, 2012 at 6:14 PM, LM wrote:

From your statements regarding people getting confused about a new tool being thrown in :-). Nevermind.

OTOH I would expect developers compiling SDL2 themselves to be able to follow a five-liner with instructions. They are/were able to do this in the past for configure and make as well.

Cheers
MarcusOn 15.08.2012, at 21:16, Mason Wheeler wrote:

I’m not confusing it with a build tool. How did you get that from what I wrote?

I’m well aware of what CMake is: it’s a pre-build tool that generates the project file for your actual build system.

From: “@Marcus_von_Appen” <@Marcus_von_Appen>
To: Mason Wheeler ; SDL Development List
Sent: Wednesday, August 15, 2012 7:25 AM
Subject: Re: [SDL] SDL2 Moving to CMake?

Mason Wheeler :

One obvious objection comes to mind: As we have so clearly seen, some people don’t even know what CMake is, let alone how to use it.

Right now, SDL is distributed with project files for popular compilers. This means that anyone with one of those compilers can pull the source code and compile right away. Throw a dependency on a complicated tool that they’ve never heard of into the mix before they can even start compiling anything, and you’ve added a significant barrier to entry.

Please do not confuse Cmake with a build system. The autotools are not a build
system either, but provide a handy set of scripts for building, once you
executed them - they are (in their purpose) the SAME as CMake.
CMake has the advantage that it not only can deal with GNU-alikes, but Win32,
OSX and whatsnot.

If you are distributing the release tarball, the end user should (and will)
find all related files for building SDL (e.g. a VS.NET solution, Makefile,
XCode project files, etc.) just as he wishes.

Even more, if he has his own $FANC_BUILD_TOOL and it is supported by CMake, he
can simply rerun CMake (here the knowledge gap you mention) would step in) for
his purposes.

The management of all those build-related files however can be centralized
with Cmake, reducing the maintenance efforts and out-of-sync problems.

Long story short:

  • no new tools for end users
  • new capabilities for developers, porters, etc.
  • less maintenance for target platform build systems

Cheers
Marcus

Can y’all take this off-list, please?

–ryan.On 8/14/12 6:55 PM, R Manard wrote:

Are you the sdl contributer and role model we are required to emulate? I
went to the cmake site and still could not understand what is was so i
asked. i see nothing wrong with that. I put about three hours total into
goofleing it YES I DID. how dare you call me a liar.

Do you care to post it or check it in?

Here’s where I was; I had quite a way to go, but I was trying to be
pedantic about converting the entire configure script, instead of going
for bulk and then refining. I can’t say if this was a good strategy or not.

Attached.

–ryan.

-------------- next part --------------

Simple DirectMedia Layer

Copyright © 1997-2012 Sam Lantinga #

This software is provided ‘as-is’, without any express or implied

warranty. In no event will the authors be held liable for any damages

arising from the use of this software.

Permission is granted to anyone to use this software for any purpose,

including commercial applications, and to alter it and redistribute it

freely, subject to the following restrictions:

1. The origin of this software must not be misrepresented; you must not

claim that you wrote the original software. If you use this software

in a product, an acknowledgment in the product documentation would be

appreciated but is not required.

2. Altered source versions must be plainly marked as such, and must not be

misrepresented as being the original software.

3. This notice may not be removed or altered from any source distribution.

project(SDL C)
cmake_minimum_required(VERSION 2.8.0)

Please update these when making new releases.

set(SDL_MAJOR_VERSION 1)
set(SDL_MINOR_VERSION 3)
set(SDL_MICRO_VERSION 0)

Some utility stuff to make the rest of the code cleaner…

Useful standard CMake macros…

include(CheckIncludeFile)
include(CheckLibraryExists)
include(CheckCSourceCompiles)
include(CheckCCompilerFlag)
include(CheckFunctionExists)
include(CheckStructHasMember)
include(CheckTypeSize)
include(TestBigEndian)

I hate that they define “WIN32” … we’re about to move to Win64…I hope!

if (WIN32 AND NOT WINDOWS)
set(WINDOWS TRUE)
elseif(APPLE AND NOT MACOSX) # Bleh, let’s do it for “APPLE” too.
set(MACOSX TRUE)
elseif(UNIX AND (CMAKE_SYSTEM_NAME STREQUAL “Linux”))
set(LINUX TRUE)
elseif(UNIX AND (CMAKE_SYSTEM_NAME STREQUAL “OpenBSD”))
set(OPENBSD TRUE)
elseif(UNIX AND (CMAKE_SYSTEM_NAME STREQUAL “NetBSD”))
set(NETBSD TRUE)
elseif(UNIX AND (CMAKE_SYSTEM_NAME STREQUAL “FreeBSD”))
set(FREEBSD TRUE)
endif()

Print a key/bool-value pair.

macro(message_bool_option _NAME _VALUE)
if(${_VALUE})
message(STATUS " ${_NAME}: ON")
else()
message(STATUS " ${_NAME}: OFF")
endif()
endmacro()

Print a key/string-value pair.

macro(message_string_option _NAME _VALUE)
message(STATUS " ${_NAME}: ‘${${_VALUE}}’")
endmacro()

This is like the built-in OPTION(), but takes a string instead of a bool.

macro(option_string _NAME _DESC _DEFLT)
set(${_NAME} “${_DEFLT}” CACHE STRING “${_DESC}”)
endmacro()

This checks if a given #define is defined at all (and not what it is set to).

macro(sdl_check_define_exists _CDEF _VALUE _HEADERS _KNOWNYES)
if (${_KNOWNYES}) # don’t launch a compiler if we don’t have to.
set(${_VALUE} TRUE)
else()
set(CMAKE_REQUIRED_INCLUDES “${_HEADERS}”)
check_c_source_compiles("
#ifdef ${_CDEF}
int main(int argc, char **argv) { int yup = 1; return 0; }
#else
#error No such preprocessor define.
#endif
" ${_VALUE}
)
set(CMAKE_REQUIRED_INCLUDES)
endif()
endmacro()

macro(sdl_check_library_exists _LIB _FN _LOC _VALUE _KNOWNYES)
if (${_KNOWNYES}) # don’t launch a compiler if we don’t have to.
set(${_VALUE} TRUE)
else()
check_library_exists("${_LIB}" “${_FN}” “${_LOC}” “${_VALUE}”)
endif()
endmacro()

macro(sdl_check_include_file _HEADER _VALUE _KNOWNYES)
if (${_KNOWNYES}) # don’t launch a compiler if we don’t have to.
set(${_VALUE} TRUE)
else()
check_include_file("${_HEADER}" “${_VALUE}”)
endif()
endmacro()

Check for stuff SDL cares about…

#set(SDL_DEBUG_BUILD ((NOT CMAKE_BUILD_TYPE) OR (CMAKE_BUILD_TYPE STREQUAL “Debug”)))

Check some lowlevel stuff first.

!!! FIXME: check for these things?

#AC_C_CONST
#AC_C_INLINE
#AC_C_VOLATILE

check_type_size(“void *” SIZEOF_VOIDP)

Now let’s look at configurable options…

See whether we are allowed to use the system C library.

option(SDL_LIBC “Use the system C library” TRUE)
if (SDL_LIBC)
SET(HAVE_LIBC 1)

# Check for C library headers
sdl_check_include_file("sys/types.h" HAVE_SYS_TYPES_H MACOSX)
sdl_check_include_file("stdio.h" HAVE_STDIO_H MACOSX)
sdl_check_include_file("stdlib.h" HAVE_STDLIB_H MACOSX)
sdl_check_include_file("stddef.h" HAVE_STDDEF_H MACOSX)
sdl_check_include_file("stdarg.h" HAVE_STDARG_H MACOSX)
sdl_check_include_file("malloc.h" HAVE_MALLOC_H LINUX)
sdl_check_include_file("memory.h" HAVE_MEMORY_H MACOSX)
sdl_check_include_file("string.h" HAVE_STRING_H MACOSX)
sdl_check_include_file("strings.h" HAVE_STRINGS_H MACOSX)
sdl_check_include_file("inttypes.h" HAVE_INTTYPES_H MACOSX)
sdl_check_include_file("stdint.h" HAVE_STDINT_H MACOSX)
sdl_check_include_file("ctype.h" HAVE_CTYPE_H MACOSX)
sdl_check_include_file("math.h" HAVE_MATH_H MACOSX)
sdl_check_include_file("iconv.h" HAVE_ICONV_H MACOSX)
sdl_check_include_file("signal.h" HAVE_SIGNAL_H MACOSX)
sdl_check_include_file("alloca.h" HAVE_ALLOCA_H MACOSX)

sdl_check_define_exists("M_PI" HAVE_M_PI "math.h" MACOSX)

set(HAVE_ALLOCA 1)   # !!! FIXME

sdl_check_library_exists("m" "pow" "" HAVE_LIBM LINUX)
if (HAVE_LIBM)
    set(SDL_EXTRA_LIBS "${SDL_EXTRA_LIBS};m")
    set(CMAKE_REQUIRED_LIBRARIES "${CMAKE_REQUIRED_LIBRARIES};m")
endif()

sdl_check_library_exists("iconv" "iconv_open" "" HAVE_LIBICONV FALSE)
if (HAVE_LIBICONV)
    set(SDL_EXTRA_LIBS "${SDL_EXTRA_LIBS};iconv")
    set(CMAKE_REQUIRED_LIBRARIES "${CMAKE_REQUIRED_LIBRARIES};iconv")
endif()

foreach( _FN
         memcmp strtod mprotect malloc calloc realloc free getenv setenv
         putenv unsetenv qsort abs bcopy memset memcpy memmove strlen
         strlcpy strlcat strdup _strrev _strupr _strlwr strchr strrchr
         strstr itoa _ltoa _uitoa _ultoa strtol strtoul _i64toa _ui64toa
         strtoll strtoull atoi atof strcmp strncmp _stricmp strcasecmp
         _strnicmp strncasecmp sscanf snprintf vsnprintf sigaction setjmp
         nanosleep sysconf sysctlbyname atan atan2 ceil copysign cos cosf
         fabs floor log pow scalbn sin sinf sqrt iconv )
    string(TOUPPER ${_FN} _UPPER)
    set(_HAVEVAR "HAVE_${_UPPER}")  # "_i64toa" becomes "HAVE__I64TOA"
    check_function_exists("${_FN}" ${_HAVEVAR})
endforeach()

set(CMAKE_REQUIRED_LIBRARIES)   # lose any "-lm", etc for further tests.

check_struct_has_member("struct sigaction" "sa_sigaction" "signal.h" HAVE_SA_SIGACTION)

endif()

See whether we want assertions for debugging/sanity checking SDL itself.

option_string(SDL_ASSERTIONS “Enable internal sanity checks (auto/disabled/release/enabled/paranoid)” “auto”)
if (SDL_ASSERTIONS STREQUAL “auto”)
# Use optimization settings to determine assertion level
elseif (SDL_ASSERTIONS STREQUAL “disabled”)
set(SDL_DEFAULT_ASSERT_LEVEL 0)
elseif (SDL_ASSERTIONS STREQUAL “release”)
set(SDL_DEFAULT_ASSERT_LEVEL 1)
elseif (SDL_ASSERTIONS STREQUAL “enabled”)
set(SDL_DEFAULT_ASSERT_LEVEL 2)
elseif (SDL_ASSERTIONS STREQUAL “paranoid”)
set(SDL_DEFAULT_ASSERT_LEVEL 3)
else()
message(FATAL_ERROR “unknown assertion level. stop.”)
endif()

!!! FIXME: do this even if atomics are disabled?

See whether we can use gcc atomic operations on this architecture.

option(GCC_ATOMICS “Use gcc builtin atomics” ${CMAKE_COMPILER_IS_GNUCC})
if (GCC_ATOMICS)
check_c_source_compiles(“
int main(int argc, char **argv) {
int a;
void *x, *y, *z;
__sync_lock_test_and_set(&a, 4);
__sync_lock_test_and_set(&x, y);
__sync_fetch_and_add(&a, 1);
__sync_bool_compare_and_swap(&a, 5, 10);
__sync_bool_compare_and_swap(&x, y, z);
return 0;
}
” HAVE_GCC_ATOMICS
)

if (NOT HAVE_GCC_ATOMICS)
    # See if we have the minimum operation needed for GCC atomics
    check_c_source_compiles("
        int main(int argc, char **argv) {
            int a;
            __sync_lock_test_and_set(&a, 1);
            __sync_lock_release(&a);
            return 0;
        }
        " HAVE_GCC_SYNC_LOCK_TEST_AND_SET
    )
endif()

endif()

Text for CPU-specific instruction sets…

option(SDL_ASSEMBLY_ROUTINES “Enable assembly routines” TRUE)

!!! FIXME: big pile of sse/mmx/altivec/etc checks should be here.

These are the core SDL sources. We’ll add files to this variable.

set(SOURCES
src/SDL.c
src/SDL_assert.c
src/SDL_compat.c
src/SDL_error.c
src/SDL_fatal.c
src/SDL_hints.c
src/SDL_log.c
src/atomic/SDL_atomic.c
src/atomic/SDL_spinlock.c
src/audio/SDL_audio.c
src/audio/SDL_audiocvt.c
src/audio/SDL_audiodev.c
src/audio/SDL_audiotypecvt.c
src/audio/SDL_mixer.c
src/audio/SDL_wave.c
src/audio/sun/SDL_sunaudio.c
src/audio/winmm/SDL_winmm.c
src/audio/xaudio2/SDL_xaudio2.c
src/cpuinfo/SDL_cpuinfo.c
src/events/SDL_clipboardevents.c
src/events/SDL_dropevents.c
src/events/SDL_events.c
src/events/SDL_gesture.c
src/events/SDL_keyboard.c
src/events/SDL_mouse.c
src/events/SDL_quit.c
src/events/SDL_touch.c
src/events/SDL_windowevents.c
src/file/SDL_rwops.c
src/haptic/SDL_haptic.c
src/joystick/SDL_joystick.c
src/power/SDL_power.c
src/render/direct3d/SDL_render_d3d.c
src/render/nds/SDL_ndsrender.c
src/render/opengl/SDL_render_gl.c
src/render/opengl/SDL_shaders_gl.c
src/render/opengles/SDL_render_gles.c
src/render/opengles2/SDL_render_gles2.c
src/render/opengles2/SDL_shaders_gles2.c
src/render/SDL_render.c
src/render/SDL_yuv_mmx.c
src/render/SDL_yuv_sw.c
src/render/software/SDL_blendfillrect.c
src/render/software/SDL_blendline.c
src/render/software/SDL_blendpoint.c
src/render/software/SDL_drawline.c
src/render/software/SDL_drawpoint.c
src/render/software/SDL_render_sw.c
src/stdlib/SDL_getenv.c
src/stdlib/SDL_iconv.c
src/stdlib/SDL_malloc.c
src/stdlib/SDL_qsort.c
src/stdlib/SDL_stdlib.c
src/stdlib/SDL_string.c
src/thread/SDL_thread.c
src/timer/SDL_timer.c
src/video/SDL_blit.c
src/video/SDL_blit_0.c
src/video/SDL_blit_1.c
src/video/SDL_blit_A.c
src/video/SDL_blit_auto.c
src/video/SDL_blit_copy.c
src/video/SDL_blit_N.c
src/video/SDL_blit_slow.c
src/video/SDL_bmp.c
src/video/SDL_clipboard.c
src/video/SDL_fillrect.c
src/video/SDL_pixels.c
src/video/SDL_rect.c
src/video/SDL_RLEaccel.c
src/video/SDL_shape.c
src/video/SDL_stretch.c
src/video/SDL_surface.c
src/video/SDL_video.c
)

Check for toplevel SDL subsystems.

macro(sdl_subsystem _NAME)
string(TOUPPER “${_NAME}” _UPPER)
set(VARNAME "SDL${_UPPER}")
option(${_VARNAME} “Enable the ${_NAME} subsystem” TRUE)
if (${$_VARNAME}})
SET(${_VARNAME}_DISABLED 1)
endif()
endmacro()

sdl_subystem(atomic)
sdl_subystem(audio)
sdl_subystem(video)
sdl_subystem(render)
sdl_subystem(events)
sdl_subystem(joystick)
sdl_subystem(haptic)
sdl_subystem(power)
sdl_subystem(threads)
sdl_subystem(timers)
sdl_subystem(file)
sdl_subystem(loadso)
sdl_subystem(cpuinfo)

See if the OSS audio interface is supported

macro(CheckOSS)
if (SDL_AUDIO)
option(SDL_OSS “support the OSS audio API” TRUE)
if (SDL_OSS)
sdl_check_include_file(“sys/soundcard.h” HAVE_SYS_SOUNDCARD_H FALSE)
if (NOT HAVE_SYS_SOUNDCARD_H)
sdl_check_include_file(“soundcard.h” HAVE_SOUNDCARD_H FALSE)
if (NOT HAVE_SOUNDCARD_H)
set(SDL_OSS FALSE)
endif()
endif()

        if (SDL_OSS)
            set(SDL_AUDIO_DRIVER_OSS 1)
            set(SOURCES $SOURCES "src/audio/dsp/SDL_dspaudio.c")
            set(HAVE_AUDIO TRUE)

            # We may need to link with ossaudio emulation library
            if (OPENBSD OR NETBSD)
                set(SDL_EXTRA_LIBS "${SDL_EXTRA_LIBS};ossaudio")
            endif()
        endif()
    endif()
endif()

endmacro()

See if the ALSA audio interface is supported

macro(CheckALSA)
if (SDL_AUDIO)
option(SDL_ALSA “support the ALSA audio API” TRUE)
if (SDL_ALSA)
include(FindALSA)
if (NOT ALSA_FOUND)
set(SDL_ALSA FALSE)
else()
set(SDL_AUDIO_DRIVER_ALSA 1)
set(SOURCES $SOURCES “src/audio/alsa/SDL_alsaaudio.c”)
set(HAVE_AUDIO TRUE)
include_directories("${ALSA_INCLUDE_DIR}")

            option(SDL_ALSA_SHARED "dynamically load ALSA audio support" TRUE)
            if (SDL_ALSA_SHARED)
                # !!! FIXME: write me.
                set(SDL_EXTRA_LIBS "${SDL_EXTRA_LIBS};${ALSA_LIBRARY}")
            else()
                set(SDL_EXTRA_LIBS "${SDL_EXTRA_LIBS};${ALSA_LIBRARY}")
            endif()
        endif()
    endif()
endif()

endmacro()

Find the ESD includes and libraries

macro(CheckESD)
if (SDL_AUDIO)
option(SDL_ESD “support the Enlightened Sound Daemon” TRUE)
if (SDL_ESD)
# !!! FIXME: make this a macro.
sdl_check_include_file(“esd.h” HAVE_ESD_H FALSE)
if (NOT HAVE_ESD_H)
set(SDL_ESD FALSE)
else()
sdl_check_library_exists(“esd” “esd_open_sound” “” HAVE_LIBESD FALSE)
if (NOT HAVE_LIBESD)
set(SDL_ESD FALSE)
else()
set(SDL_AUDIO_DRIVER_ESD 1)
set(SOURCES $SOURCES “src/audio/esd/SDL_esdaudio.c”)
set(HAVE_AUDIO TRUE)
#include_directories("${ESD_INCLUDE_DIR}")

                option(SDL_ESD_SHARED "dynamically load ESD audio support" TRUE)
                if (SDL_ESD_SHARED)
                    # !!! FIXME: write me.
                    set(SDL_EXTRA_LIBS "${SDL_EXTRA_LIBS};esd")
                else()
                    set(SDL_EXTRA_LIBS "${SDL_EXTRA_LIBS};esd")
                endif()
            endif()
        endif()
    endif()
endif()

endmacro()

set(SDL_VERSION “${SDL_MAJOR_VERSION}.${SDL_MINOR_VERSION}.${SDL_MICRO_VERSION}”)

include_directories(".")
include_directories(“include”)

if (CYGWIN)
add_definitions("-I/usr/include/mingw -mno-cygwin")
add_ldflags("-mno-cygwin")
endif()

add_library(SDL SHARED ${SOURCES})

end of CMakeLists.txt …

#enable_language(CXX)
set(ignoreme
src/audio/alsa/SDL_alsa_audio.c
src/audio/android/SDL_androidaudio.c
src/audio/arts/SDL_artsaudio.c
src/audio/bsd/SDL_bsdaudio.c
src/audio/coreaudio/SDL_coreaudio.c
src/audio/directsound/SDL_directsound.c
src/audio/disk/SDL_diskaudio.c
src/audio/dsp/SDL_dspaudio.c
src/audio/dummy/SDL_dummyaudio.c
src/audio/esd/SDL_esdaudio.c
src/audio/fusionsound/SDL_fsaudio.c
src/audio/nas/SDL_nasaudio.c
src/audio/nds/SDL_ndsaudio.c
src/audio/paudio/SDL_paudio.c
src/audio/pulseaudio/SDL_pulseaudio.c
src/audio/qsa/SDL_qsa_audio.c
src/core/windows/SDL_windows.c
src/events/nds/SDL_ndsgesture.c
src/haptic/darwin/SDL_syshaptic.c
src/haptic/dummy/SDL_syshaptic.c
src/haptic/linux/SDL_syshaptic.c
src/haptic/nds/SDL_syshaptic.c
src/haptic/windows/SDL_syshaptic.c
src/joystick/android/SDL_sysjoystick.c
src/joystick/bsd/SDL_sysjoystick.c
src/joystick/darwin/SDL_sysjoystick.c
src/joystick/dummy/SDL_sysjoystick.c
src/joystick/linux/SDL_sysjoystick.c
src/joystick/nds/SDL_sysjoystick.c
src/joystick/windows/SDL_dxjoystick.c
src/joystick/windows/SDL_mmjoystick.c
src/libm/e_atan2.c
src/libm/e_log.c
src/libm/e_pow.c
src/libm/e_rem_pio2.c
src/libm/e_sqrt.c
src/libm/k_cos.c
src/libm/k_rem_pio2.c
src/libm/k_sin.c
src/libm/s_atan.c
src/libm/s_copysign.c
src/libm/s_cos.c
src/libm/s_fabs.c
src/libm/s_floor.c
src/libm/s_scalbn.c
src/libm/s_sin.c
src/loadso/beos/SDL_sysloadso.c
src/loadso/dlopen/SDL_sysloadso.c
src/loadso/dummy/SDL_sysloadso.c
src/loadso/windows/SDL_sysloadso.c
src/main/dummy/SDL_dummy_main.c
src/main/windows/SDL_windows_main.c
src/power/beos/SDL_syspower.c
src/power/linux/SDL_syspower.c
src/power/macosx/SDL_syspower.c
src/power/nds/SDL_syspower.c
src/power/windows/SDL_syspower.c
src/thread/beos/SDL_syssem.c
src/thread/beos/SDL_systhread.c
src/thread/generic/SDL_syscond.c
src/thread/generic/SDL_sysmutex.c
src/thread/generic/SDL_syssem.c
src/thread/generic/SDL_systhread.c
src/thread/nds/SDL_syscond.c
src/thread/nds/SDL_sysmutex.c
src/thread/nds/SDL_syssem.c
src/thread/nds/SDL_systhread.c
src/thread/pthread/SDL_syscond.c
src/thread/pthread/SDL_sysmutex.c
src/thread/pthread/SDL_syssem.c
src/thread/pthread/SDL_systhread.c
src/thread/windows/SDL_sysmutex.c
src/thread/windows/SDL_syssem.c
src/thread/windows/SDL_systhread.c
src/thread/windows/win_ce_semaphore.c
src/timer/beos/SDL_systimer.c
src/timer/dummy/SDL_systimer.c
src/timer/nds/SDL_systimer.c
src/timer/unix/SDL_systimer.c
src/timer/wince/SDL_systimer.c
src/timer/windows/SDL_systimer.c
src/video/android/SDL_androidevents.c
src/video/android/SDL_androidgl.c
src/video/android/SDL_androidkeyboard.c
src/video/android/SDL_androidtouch.c
src/video/android/SDL_androidvideo.c
src/video/android/SDL_androidwindow.c
src/video/directfb/SDL_DirectFB_dyn.c
src/video/directfb/SDL_DirectFB_events.c
src/video/directfb/SDL_DirectFB_modes.c
src/video/directfb/SDL_DirectFB_mouse.c
src/video/directfb/SDL_DirectFB_opengl.c
src/video/directfb/SDL_DirectFB_render.c
src/video/directfb/SDL_DirectFB_shape.c
src/video/directfb/SDL_DirectFB_video.c
src/video/directfb/SDL_DirectFB_window.c
src/video/directfb/SDL_DirectFB_WM.c
src/video/dummy/SDL_nullevents.c
src/video/dummy/SDL_nullframebuffer.c
src/video/dummy/SDL_nullvideo.c
src/video/nds/SDL_ndsevents.c
src/video/nds/SDL_ndsvideo.c
src/video/nds/SDL_ndswindow.c
src/video/pandora/SDL_pandora.c
src/video/pandora/SDL_pandora_events.c
src/video/uikit/jumphack.c
src/video/windows/SDL_windowsclipboard.c
src/video/windows/SDL_windowsevents.c
src/video/windows/SDL_windowsframebuffer.c
src/video/windows/SDL_windowskeyboard.c
src/video/windows/SDL_windowsmodes.c
src/video/windows/SDL_windowsmouse.c
src/video/windows/SDL_windowsopengl.c
src/video/windows/SDL_windowsshape.c
src/video/windows/SDL_windowsvideo.c
src/video/windows/SDL_windowswindow.c
src/video/x11/imKStoUCS.c
src/video/x11/SDL_x11clipboard.c
src/video/x11/SDL_x11dyn.c
src/video/x11/SDL_x11events.c
src/video/x11/SDL_x11framebuffer.c
src/video/x11/SDL_x11keyboard.c
src/video/x11/SDL_x11modes.c
src/video/x11/SDL_x11mouse.c
src/video/x11/SDL_x11opengl.c
src/video/x11/SDL_x11opengles.c
src/video/x11/SDL_x11shape.c
src/video/x11/SDL_x11touch.c
src/video/x11/SDL_x11video.c
src/video/x11/SDL_x11window.c
)

Right now, SDL is distributed with project files for popular compilers.
This means that anyone with one of those compilers can pull the source
code and compile right away. Throw a dependency on a complicated tool
that they’ve never heard of into the mix before they can even start
compiling anything, and you’ve added a significant barrier to entry.

This is a fair point, but I would counter that:

a) Project files all need to be maintained, and there have been many
instances where we’ve updated one and not the others as changes are
required (even on Windows, people tend to update the .vcproj for just
their version of Visual Studio). Lots of times, we’ve had broken project
files and not known it. Before I started running buildbot, they were
broken even more.

b) There have been many times when the Visual Studio files are broken
for any number of reasons (in general, if I download a project and it
used VS2005 and I’ve got VS2008, I assume Microsoft’s own tools will
screw up the project conversion, for one example). If the end-user is
willing to use CMake, I suspect they get better results from the .vcproj
generated specifically for their system.

c) I consider using CMake to be an acceptable barrier to entry for those
that care about SDL at the source code level. We will definitely make
sure we have concise instructions in a README for getting it running,
but the tl;dr of it is "install the thing at cmake.org, point it at the
source tree and click “generate”, use whatever development environment
you like after that.

–ryan.

Use CMake internally to build Visual C++ project files and distribute
the generated Visual C++ project files along with the rest of the
package. Whoever downloads a distribution just loads these files into VC
and never touches CMake. Works with other compilers as well, and beats
maintaining different project files by hand.

I’m pretty sure CMake tends to hardcode file paths in the project
files…works fine on your system, but they assume anyone else will
generate their own instead of using your copy.

This might be something they fixed, or something I’ve been doing wrong,
though.

–ryan.

CMake does generate hardcoded file paths in the generated project files.
That’s by design though.

Instead of distributing the generated files, the intent is that you
distribute the CMakeFile.txt, and each person intending to build the
project generates their own project files.

Cheers,
NoahOn Wed, Aug 15, 2012 at 5:07 PM, Ryan C. Gordon wrote:

Use CMake internally to build Visual C++ project files and distribute

the generated Visual C++ project files along with the rest of the
package. Whoever downloads a distribution just loads these files into VC
and never touches CMake. Works with other compilers as well, and beats
maintaining different project files by hand.

I’m pretty sure CMake tends to hardcode file paths in the project
files…works fine on your system, but they assume anyone else will
generate their own instead of using your copy.

This might be something they fixed, or something I’ve been doing wrong,
though.

–ryan.

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On, Thu Aug 16, 2012, Ryan C. Gordon wrote:

Do you care to post it or check it in?

Here’s where I was; I had quite a way to go, but I was trying to be
pedantic about converting the entire configure script, instead of going
for bulk and then refining. I can’t say if this was a good strategy or not.

Attached.

Thanks, I merged the useful looking pieces with my own progress.

Cheers
Marcus
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20120818/b7307ee2/attachment.pgp

As purely a biased and personal view on cmake, I loathe dealing with it.

Sure, it works, it’s just a vertical cliff to climb with no instruction manual, when all I wanted to do was “make”.

That said I’m also not at all fond of autotools (automake and libtool) and have only a passing tolerance for configure.

I recognize the uses of these tools and the acceptance of them, they just annoy me more often than they help, with cmake-gui being the single worst offender.On 08/15/2012 05:05 PM, Ryan C. Gordon wrote:

Right now, SDL is distributed with project files for popular compilers.
This means that anyone with one of those compilers can pull the source
code and compile right away. Throw a dependency on a complicated tool
that they’ve never heard of into the mix before they can even start
compiling anything, and you’ve added a significant barrier to entry.

This is a fair point, but I would counter that:

a) Project files all need to be maintained, and there have been many instances where we’ve updated one and not the others as changes are required (even on Windows, people tend to update the .vcproj
for just their version of Visual Studio). Lots of times, we’ve had broken project files and not known it. Before I started running buildbot, they were broken even more.

b) There have been many times when the Visual Studio files are broken for any number of reasons (in general, if I download a project and it used VS2005 and I’ve got VS2008, I assume Microsoft’s own
tools will screw up the project conversion, for one example). If the end-user is willing to use CMake, I suspect they get better results from the .vcproj generated specifically for their system.

c) I consider using CMake to be an acceptable barrier to entry for those that care about SDL at the source code level. We will definitely make sure we have concise instructions in a README for getting
it running, but the tl;dr of it is "install the thing at cmake.org, point it at the source tree and click “generate”, use whatever development environment you like after that.

–ryan.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

Hm… Well, let me not start on autotools, because we’ll be here all
day. Suffice to say, I disagree vehemently.

Tangibly though, cmake offers the following benefits, which I for one
am very much looking forward to:

  • 1st class non-unix build environment builds (visual studio, xcode,
    code blocks, etc.)

  • No 5 minute initial autotools configuration step (you laugh, but I
    use msys for a few things, and it actually takes about 6 minutes on my
    machine)

  • Native and full support for non-destructive build directories
    (configure --prefix=BLAH would be great if it actually worked…)

If you don’t like cmake… well, that’s unfortunate. All I can say it
perhaps give ccmake a try, or just use the cmake -DOPTION=VALUE
command to build without using ccmake or cmake-gui.

I really see this as a step forward for SDL~

(To be clear; I dont think cmake is the Answer To All Problems, but
anything which is not autotools, automake and configure is a blessing
as far as I’m concerned; even plain on makefiles (that’s what lua
does, and it works for them, although to be fair, they have to handle
no external dependencies)).~
Doug.

On Sun, Aug 19, 2012 at 1:23 PM, Forest Hale wrote:

As purely a biased and personal view on cmake, I loathe dealing with it.

Sure, it works, it’s just a vertical cliff to climb with no instruction manual, when all I wanted to do was “make”.

That said I’m also not at all fond of autotools (automake and libtool) and have only a passing tolerance for configure.

I recognize the uses of these tools and the acceptance of them, they just annoy me more often than they help, with cmake-gui being the single worst offender.

On 08/15/2012 05:05 PM, Ryan C. Gordon wrote:

Right now, SDL is distributed with project files for popular compilers.
This means that anyone with one of those compilers can pull the source
code and compile right away. Throw a dependency on a complicated tool
that they’ve never heard of into the mix before they can even start
compiling anything, and you’ve added a significant barrier to entry.

This is a fair point, but I would counter that:

a) Project files all need to be maintained, and there have been many instances where we’ve updated one and not the others as changes are required (even on Windows, people tend to update the .vcproj
for just their version of Visual Studio). Lots of times, we’ve had broken project files and not known it. Before I started running buildbot, they were broken even more.

b) There have been many times when the Visual Studio files are broken for any number of reasons (in general, if I download a project and it used VS2005 and I’ve got VS2008, I assume Microsoft’s own
tools will screw up the project conversion, for one example). If the end-user is willing to use CMake, I suspect they get better results from the .vcproj generated specifically for their system.

c) I consider using CMake to be an acceptable barrier to entry for those that care about SDL at the source code level. We will definitely make sure we have concise instructions in a README for getting
it running, but the tl;dr of it is "install the thing at cmake.org, point it at the source tree and click “generate”, use whatever development environment you like after that.

–ryan.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Howdy,

Due to recent painful experience, I can’t help but chime in.

I’m certainly no expert on build systems, but having fought with make for
the better part of the past year at work, and having fought with cmake
absolutely every single time I ever tried to use it, I have to say, I
haven’t heard any good justifications why a competent programmer can’t just
whip up a simplistic python program to script and define build rules for
their project. To anyone who says why not have a tool that many people use,
I say: fine, make such a tool and share it, but make it from a programming
language that is explicit, procedural, has as few rules as possible to
define build targets, variables, and dependencies.

My argument boils down to the observation that whatever feature make has
that I’m likely to ever use, I’m certain I can do it easily with a python,
with the advantages that:

  • an explicit script is more readable than the countless poorly explained
    implicit rules of make (doesn’t CMake have implicit rules of its own? I
    don’t like those!)
  • an explicit script clearly defines every variable and function, rather
    than having to know which contexts allow which syntax, which state is
    reached after which sequence of bizarre characters, etc.
  • a modern programming language has a relatively simple syntax and keyword
    set (for any intermediate programmer), whereas make has a syntax with
    variable and poorly defined meaning (having colons, hyphens and other worse
    symbols have specific yet hard-to-divine meanings in all the different
    ’parts’ of a makefile is not fun to figure out; this is especially so in a
    very large legacy build system)
  • an explicit script can be much more easily debugged and tooled than a
    make file.
  • when I try to parallelize build commands that have their dependencies
    resolved, I will never again see the message “job server isn’t happy about
    XYZ/meaningless message, so I will not parallelize. Enjoy this inflexible
    and unexplained behavior”.

Honestly, I think any build system I’m likely to use in the future will
look more like a regular program and less like an arcane set of prayers
based on absent explanations, or verbose yet seemingly laughably convoluted
rules and protocols. I believe a programmer’s work (especially work
destined to be used and possibly reviewed by others) should err much closer
towards clarity than towards sticking to standards which at this time in
computer history seem thoroughly arbitrary.

Thanks for your time and good luck :slight_smile:

  • ChristianOn Sun, Aug 19, 2012 at 6:46 AM, Doug <douglas.linder at gmail.com> wrote:

Hm… Well, let me not start on autotools, because we’ll be here all
day. Suffice to say, I disagree vehemently.

Tangibly though, cmake offers the following benefits, which I for one
am very much looking forward to:

  • 1st class non-unix build environment builds (visual studio, xcode,
    code blocks, etc.)

  • No 5 minute initial autotools configuration step (you laugh, but I
    use msys for a few things, and it actually takes about 6 minutes on my
    machine)

  • Native and full support for non-destructive build directories
    (configure --prefix=BLAH would be great if it actually worked…)

If you don’t like cmake… well, that’s unfortunate. All I can say it
perhaps give ccmake a try, or just use the cmake -DOPTION=VALUE
command to build without using ccmake or cmake-gui.

I really see this as a step forward for SDL~

(To be clear; I dont think cmake is the Answer To All Problems, but
anything which is not autotools, automake and configure is a blessing
as far as I’m concerned; even plain on makefiles (that’s what lua
does, and it works for them, although to be fair, they have to handle
no external dependencies)).

~
Doug.

On Sun, Aug 19, 2012 at 1:23 PM, Forest Hale wrote:

As purely a biased and personal view on cmake, I loathe dealing with it.

Sure, it works, it’s just a vertical cliff to climb with no instruction
manual, when all I wanted to do was “make”.

That said I’m also not at all fond of autotools (automake and libtool)
and have only a passing tolerance for configure.

I recognize the uses of these tools and the acceptance of them, they
just annoy me more often than they help, with cmake-gui being the single
worst offender.

On 08/15/2012 05:05 PM, Ryan C. Gordon wrote:

Right now, SDL is distributed with project files for popular compilers.
This means that anyone with one of those compilers can pull the source
code and compile right away. Throw a dependency on a complicated tool
that they’ve never heard of into the mix before they can even start
compiling anything, and you’ve added a significant barrier to entry.

This is a fair point, but I would counter that:

a) Project files all need to be maintained, and there have been many
instances where we’ve updated one and not the others as changes are
required (even on Windows, people tend to update the .vcproj

for just their version of Visual Studio). Lots of times, we’ve had
broken project files and not known it. Before I started running buildbot,
they were broken even more.

b) There have been many times when the Visual Studio files are broken
for any number of reasons (in general, if I download a project and it used
VS2005 and I’ve got VS2008, I assume Microsoft’s own

tools will screw up the project conversion, for one example). If the
end-user is willing to use CMake, I suspect they get better results from
the .vcproj generated specifically for their system.

c) I consider using CMake to be an acceptable barrier to entry for
those that care about SDL at the source code level. We will definitely make
sure we have concise instructions in a README for getting

it running, but the tl;dr of it is "install the thing at cmake.org,
point it at the source tree and click “generate”, use whatever development
environment you like after that.

–ryan.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


LordHavoc
Author of DarkPlaces Quake1 engine -
http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged
demo." - James Klass
"A game is a series of interesting choices." - Sid Meier


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I’m certainly no expert on build systems, but having fought with make for
the better part of the past year at work, and having fought with cmake
absolutely every single time I ever tried to use it, I have to say, I
haven’t heard any good justifications why a competent programmer can’t just
whip up a simplistic python program to script and define build rules for
their project. To anyone who says why not have a tool that many people use,
I say: fine, make such a tool and share it, but make it from a programming
language that is explicit, procedural, has as few rules as possible to
define build targets, variables, and dependencies.

My argument boils down to the observation that whatever feature make has
that I’m likely to ever use, I’m certain I can do it easily with a python,
with the advantages that:

  • an explicit script is more readable than the countless poorly explained
    implicit rules of make (doesn’t CMake have implicit rules of its own? I
    don’t like those!)
  • an explicit script clearly defines every variable and function, rather
    than having to know which contexts allow which syntax, which state is
    reached after which sequence of bizarre characters, etc.
  • a modern programming language has a relatively simple syntax and keyword
    set (for any intermediate programmer), whereas make has a syntax with
    variable and poorly defined meaning (having colons, hyphens and other worse
    symbols have specific yet hard-to-divine meanings in all the different
    ’parts’ of a makefile is not fun to figure out; this is especially so in a
    very large legacy build system)
  • an explicit script can be much more easily debugged and tooled than a
    make file.
  • when I try to parallelize build commands that have their dependencies
    resolved, I will never again see the message “job server isn’t happy about
    XYZ/meaningless message, so I will not parallelize. Enjoy this inflexible
    and unexplained behavior”.

Honestly, I think any build system I’m likely to use in the future will
look more like a regular program and less like an arcane set of prayers
based on absent explanations, or verbose yet seemingly laughably convoluted
rules and protocols. I believe a programmer’s work (especially work
destined to be used and possibly reviewed by others) should err much closer
towards clarity than towards sticking to standards which at this time in
computer history seem thoroughly arbitrary.

I completely understand where you’re coming from with this, however, I
don’t think this is as maintainable as you think - developing our own
custom project generator would be cool, however, it doesn’t have the
maturity that we’d really have to depend on with a project generator like
cmake or autotools. At that rate, we’d be better of just making bash and
batch scripts (for *nix and win32, respectively), and that is a bad idea.

That being said, I do know that for as many good experiences people have
with CMake, there are also some not so good experiences. I don’t speak for
anyone other than myself, but it’s my opinion that the SDL community
doesn’t have the time or resources to develop a fully functional project
generator that supports all major IDEs.

Maybe there are other alternatives we want to look at, like Premake, or
Scons?

-AlexOn Sun, Aug 19, 2012 at 3:06 PM, Christian Leger <chrism.leger at gmail.com>wrote:

Message-ID:
<CAHgimD9H8fPMj7QR4XnY=1-AEfUDpW7s89__WqVaxyYqSw3Ebw at mail.gmail.com>
Content-Type: text/plain; charset=“iso-8859-1”

<snip, synopsis: I find Make and CMake painful, and recommend Python>

I disagree. Make is (or at least started as) a logic language (like
Prolog), and having used it for a few projects, my only quibble is
that it isn’t a more generalized language. I consider procedural
languages (such as Python) to be a bad fit to what Make is used for,
because of the particular way that they’re explicit (e.g. you specify
the order of execution). If I had to use another language, I would use
either something make-ish, or shell scripts, NOT python.

As for CMake, I’ve never written code for it, so I just don’t know.> Date: Sun, 19 Aug 2012 15:06:41 -0400

From: Christian Leger <chrism.leger at gmail.com>
To: SDL Development List
Subject: Re: [SDL] SDL2 Moving to CMake?

I completely agree that maintainability is important, and at my previous
employer that boiled down to ‘out of our 30 guys in the programming team,
having the one guy who knows more than a trivial amount about our build
system is better than zero guys’ … and nobody seemed concerned about the
long-term importance of having regular coders be able to jump into and
modify the system. It was definitely a case of preferring to think we’re
saving money by not overhauling our system (migrating to CMake, or waf, or
something else entirely) yet paying a non-trivial cost every time we needed
something new out of the ol’ pile of makefiles.

While no doubt it would be illuminating (yet be a digression meant for some
other forum) if I requested supporting evidence for claims like ‘procedural
languages are a bad fit for X’ - I suspect the real reason for such belief
is that people are easily tempted to think a problem is ‘solved’ if
so-called mature projects have been the de-facto go-to solution for long
enough. Solved? Maybe, with reservations. The best we can do – and for all
criteria? I doubt it.

I think maintainability of any system is as dependent on its underlying
design as it is on any special property of Make. While prolog-style logic
can prove adequate for certain problems, that in no way justifies all the
hurdles one encounters when trying to use Make.

When you’ve taken the time to learn something, especially something arcane
that makes you valuable to those who don’t share that knowledge, it’s
understandable that you don’t want this niche you’ve carved for yourself to
evaporate into nothing. But our technologies are in many ways still in
their infancy. Look at the number of people who are still actively trying
to solve this ‘solved’ problem (and this number seems to be growing over
time). I think that’s a strong indicator that there is progress yet to be
made, and this kind of conversation - making suggestions, even trying
things (which I intend to do in the medium term) and seeing what sticks -
is to the benefit of all interested parties.

I make several of my points because I’m an unabashed optimistic futurist,
and while I dream of improving everything I can, and try when I see
opportunities, I certainly don’t dare take away anybody’s right to continue
with what works for them. I’m simply VERY interested in constructive
discussions which might, at some point, lead to build systems that seem
more natural to those of us that have struggled with make, yet can imagine
in their very own heads a system that would work for their current needs.

Of course, in the case of SDL, if existing tools are unanimously judged to
be (or according to the people who decide) unimprovable, then they will
stay right where they are.

Regards,

ChristianOn Mon, Aug 20, 2012 at 3:32 AM, Jared Maddox wrote:

Date: Sun, 19 Aug 2012 15:06:41 -0400
From: Christian Leger <@Christian_Leger>
To: SDL Development List
Subject: Re: [SDL] SDL2 Moving to CMake?
Message-ID:
<CAHgimD9H8fPMj7QR4XnY=
1-AEfUDpW7s89__WqVaxyYqSw3Ebw at mail.gmail.com>
Content-Type: text/plain; charset=“iso-8859-1”

<snip, synopsis: I find Make and CMake painful, and recommend Python>

I disagree. Make is (or at least started as) a logic language (like
Prolog), and having used it for a few projects, my only quibble is
that it isn’t a more generalized language. I consider procedural
languages (such as Python) to be a bad fit to what Make is used for,
because of the particular way that they’re explicit (e.g. you specify
the order of execution). If I had to use another language, I would use
either something make-ish, or shell scripts, NOT python.

As for CMake, I’ve never written code for it, so I just don’t know.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org