[SDL] Non-API changes I'd like to see in SDL 2.0

[Edward Cullen]

Along side my study of API Usability (please check out my other post
about this and help me to help make SDL better!), I have some views on
things that I feel need to be changed...

1. No CMake or other Make front-ends.

There is no substitute for the Make manual, that is to say, RTFM and
understanding how Make works allows you to write Makefiles that do
exactly what you want them to do. Using a front-end like CMake is a
distraction; you have to learn CMake AND Make (to understand problems
when they occur).

Granted, CMake does have some useful features, such as generating
project files for other IDEs, but the thing is, you have to manually
test the output of CMake before you release the files, so you may as
well just maintain the project files manually and skip the additional
dependency.

2. No Libtool.

Libtool is brain-damaged. Sorry. The objective of libtool is laudable
and it may actually have been useful at some point in the past, however,
it is my strongly-held view that it is not possible to adequately
abstract something as fundamentally system-dependant as library management.

Basically, every system has different methods and conventions for using
dynamic libraries, some of which are fundamentally different. It is my
view that the library binary should conform to the conventions of the
underlying system, NOT some idea of 'how it should be done on every
platform'.

3. Lib binary should be libSDL.so.2 on Linux SDL2.dll on Windows.

This follows from point 2; each OS has its own conventions, Library
management is FUNDAMENTALLY different on Linux and Windows. Windows
struggles to manage different versions of dlls, Linux does it elegantly
(as long as you stick to the conventions set out in the HOWTO -
http://tldp.org/HOWTO/Program-Library-HOWTO/)

I feel that it is more important to be consistent with the underlying OS
than to attempt to be consistent about something that simply cannot be
consistent no matter how hard you try. Indeed, this is something that
you Just Have To Live With when working on many platforms; when using
dynamic libraries, you have to pass different filenames to dlopen() or
its equivalent.

4. Proper API Specification

This isn't strictly related to the work I'm doing on API Usability,
but is, fortunately, something that my work will hopefully correct - I
believe, strongly, that SDL CAN join OpenGL as a de-facto standard for
doing the job it does. However, in order to do this, it must be clearly
defined. I feel that properly defining the API will help in this, as it
will allow others to write implementations,

For example, a company might want to use the reference implementation to
develop on a desktop, but may need a non-(L)GPL implementation for its
embedded product. Having a clear, open definition of the API would
facilitate this.

5. ABI Specification(s)

Related to 4; a product developer may want to expose their own
implementation of SDL, a clear ABI specification would be necessary to
facilitate this, as is done with OpenGL...

Lots of Love!

Eddy