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

Mon Mar 10 11:24:54 PDT 2008

On 3/10/08, Edward Cullen <eac203 at ecs.soton.ac.uk> wrote:
>
> 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...

I am very glad to see that you want to make SDL better. First off, please
define better. Seriously, until you define the term "better"  you have no
idea what you need to do to make it better.

AFAICT from reading your post you have been listening to your professors and
reading your books but you lack the experience and historical knowledge to
understand that you do *not* understand what you think you have learned :-)
But, don't worry about it very much, few if any of your professors
understand what they think they are teaching.

Do I sound arrogant? Yes I do. Sorry about that. Please do not take any of
what I am about to say personally.

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.

This is your opinion and I am sure that you can find people who agree with
it. OTOH, I am sure you can find people who disagree with it. Seriously, the
choice to use a build tool is personal and directly related to your needs.
Try building the X server without using the build system provided for it.

Have you ever managed a code base larger than 100KLOCs/ (KLOC == Kilo Lines
Of Code.) Try managing a multi-MLOC project with just make. Oh my.

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'.

Same comment as above.

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.

I'm sure your suggestion will be noted. I take it you do not have an opinion
on what they should be called on Mac OS, or any of the many many other OSes
supported by SDL?  Anywayt Sam will pick the names based on Sam's opinion of
what they should be. Please note that Sam is one hell of fine programmer
with experience that is both broad and deep on all three major OSes.

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.

Again, please define the term "proper".  I do not think you know what an API
specification is or the purpose of an API specification. Anyway, SDL has the
best possible API specification, the working code that can be downloaded and
examined by anyone who wants to. No other API specification has any real
meaning. Here is something to learn and understand, dare I say "grok"?
Documents lie. Human language is inexact. Code does not lie. Use the source,
Luke.

Not to mention that the specification is still evolving. The theory behind
written formal interface specifications is that you can write an interface
in English (or any other human language) and know what it means in terms of
working code. But, you can't. The only specification that is even vaguely
unambiguous is working source code in a relatively well understood language.
The only way to evaluate the specification is to use it.

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...

Ahh crap... There is no need for an ABI specification. Given the C function
call interface, i.e. the .h files for SDL and the linkage rules for your
favorite C compiler you *have* the ABI for SDL. The ABI for a library
changes every time the compiler changes its linkage interface. If you
*look* at the .h files for SDL you will find that it already uses very
specific types when they are needed and generic types when they are not.

You mentioned OpenGL. Do you have any idea how many years experimentation
and user experience went into GL before there was version 1.0 of OpenGL? Do
you understand the business and political reasons that went into opening GL?
Did you ever look at the initial public release of OpenGL? By that I mean
the code and the documentation? You need to get some historical insight into
what you are talking about.

Lots of Love!

I can tell that you mean well and that you are dedicated to helping SDL be
better. If you really want to help please down load the 1.3 source, build
it, test it, report bugs you find, and do some serious coding with it before
you try to tell people how to run the project.

Before I decided to get seriously involved in the SDL project I spent
several months writing test programs just to make sure that I understood the
project well enough to have an opinion. That is a *after* reading the
available documentation from all sources and reading all the .h files. You
might want to do the same thing with 1.3.

Eddy

Bob Pendleton

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

-- 

+ Bob Pendleton: writer and programmer
+ email: Bob at Pendleton.com
+ web: www.GameProgrammer.com
+ www.Wise2Food.com

+--------------------------------------+
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20080310/d230c799/attachment.html 