Bob Pendleton 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.
If you took the time to read the post I was referring to, you would see
that by ‘better’ I mean empirically provable that the APIs are easier to
use.
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.
shrug I’m sorry that you feel that way, as you are, quite simply, wrong.
As well as being a university undergraduate - at one of the top
universities for Computer Science in the world; one of two places that
Tim Berners-Lee holds a chair (the other being MIT), the university
rated 3rd in THE WORLD for citations of its research (after MIT and
CalTech), an institution where many of the academics have spent MANY
years in industry, before going into research - get the idea?
As well as being an undergraduate, I also work for a small consumer
electronics company that you may have heard of - Sony - and have done so
for over a year. I am, therefore, rubbing shoulders with VERY
experienced, professional and all-round great Software Engineers, who
are more than happy to discuss the ideas I have and share their
experience and expertise with me.
Do I sound arrogant? Yes I do. Sorry about that. Please do not take any
of what I am about to say personally.
More like condescending…
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.
The Linux kernel seems to do okay, that’s managed with Make.
As is the code I work on at Sony for that matter. Make seems to do the
job there too.
Granted both have the odd helper script, but they are exactly that -
helpers, the builds themselves are managed by make.
The point I was trying to make (no pun!), was that if you understand how
to use Make and structure your project correctly, managing with 'raw’
Make is no more difficult than using any other build system.
It is my opinion that the reason people ‘struggle’ with or 'dislike’
Make, is that they begin using it without fully understanding it and as
their project grows (and their experience with Make), they find that it
is very difficult or just too time consuming to refactor the build
system into something they deem satisfactory.
I strongly disagree that the choice of build tool is a 'personal’
preference. If you wish to distribute source code widely, then you have
to be very careful about how you package it and what dependencies you
impose on the end user - not everyone who might build SDL is a developer
and therefore may not be confident manually resolving all the dependencies.
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.
So, does that mean you like Libtool or not? Do you agree or disagree
that Libtool is useful?
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?
No, because I don’t use MacOS and don’t understand how it handles
dynamic libraries. I DO use Windows and Linux. I DO understand how THEY
use dynamic libraries. I DO understand that each OS handles dynamic
libraries differently. There are so many OSes, so many different ways of
handling dynamic libraries, that you can’t adequately define a generic
way of handling them, so rather than trying and ending up with something
half-arsed, I am of the OPINION that it is better to keep it simple and
clear by saying ‘sorry, but you just have to learn how that target OS
handles libraries’. Kinda along the lines of that classic prayer (sorry,
my Dad was really religious; sometimes these things just rub off on you…)
Give me the serenity to accept the things I can't change,
The courage to change the things I can,
And the wisdom to know the difference.
Anywayt Sam will pick the names based on Sam’s opinion of what they should be.
No Shit Sherlock? But you know, he may just listen to what other people
think and he might decide that, actually, that would be a better way of
doing things, I’ll give it a go. But if no one ever suggested different
ways of doing things, then, he wouldn’t have that choice, would he?
Please note that Sam is one hell of fine programmer with experience that is
both broad and deep on all three major OSes.
Did I say that he wasn’t? Infact, if you took the time to read my post
about API usability, you will not that I acknowledge his (and Ryan’s)
experience / expertise in a very clear, unambiguous way… I’ll quote it
for you:
“I am NOT interested in the capabilities of SDL - this is a question for
Sam and Ryan, who, as professional game developers, are in a MUCH better
position to judge what is and is not necessary.”
Is that kissy-arse enough for you? Personally, I don’t think either Sam
or Ryan give a damn what you or I think about them; you don’t become
successful by being bothered in that way.
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.
Sigh A ‘proper’ specification, is a written document that is entirely
self-contained, defining clearly what the APIs are, what their
behaviours should be, how errors are defined/handled and what errors are
produced - everything a developer would need in order to implement a
conformant implementation.
Did you actually read the example I gave? Where the question was about
keeping a second implementation (L)GPL free. If you don’t understand
that, you need to brush up your copyright knowledge - If I copy from a
(L)GPL header into my own source, then I am using (L)GPL code.
therefore, my implementation is (L)GPL. I’m actually quit angry now,
because you seem to have decided that ‘because I’m a student, I don’t
know what I’m on about’, yet you haven’t really done a lot to
demonstrate that you understand what I have tried to say or that you
have even read my post properly before replying to it.
You may wish to lookup ‘clean room design’ for some ‘historical
perspective’.
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.
Now who’s not understanding what’s going on?
OpenGL is defined in a standards document. C, C++, C# etc, etc, etc are
defined in standards documents. It is possible. It has been proven
REPEATEDLY that it is possible.
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.
Um, do you actually understand WHAT an ABI is and how it works? OpenGL
has an ABI. That is why nVidia, ATI or whoever can write their own
implementation and I can then link dynamically to an ATI implementation
at compile time and (assuming same platform etc) move that binary to an
nVidia implementation and it will ‘just work’.
To be fair, you’re right, there IS no need to define ABI(s) - UNLESS you
want to make SDL as popular/widespread/supported as OpenGL… which is
exactly what I want to do.
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.
I really don’t know what to say to that… especially as you’re
comparing apples and oranges; GL was a PROPRIETARY, CLOSED SOURCE,
graphics programming language. OpenGL was simply a marketing trick; a
way of selling SGI workstations (because they were the only thing that
could actually do OpenGL properly at the time), without making people
feel ‘tied’ to SGI (The Illusion of Choice).
Going from SDL to ‘OpenSDL’ isn’t anything like the same. I even feel
bad pre-pending ‘Open’ to the front, because SDL IS ALREADY OPEN, it’s
just not as rigorously defined as OpenGL or other standards. There are
no business or political reasoning behind wanting to make SDL more
popular; all reasons are purely personal; sense of professional pride,
accomplishment, amongst others. I don’t know (care?) what Sam and Ryan’s
motivations are, but they seem to care about SDL - I care about it too.
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.
? Was the title of my post “Things that Have to Change in SDL 2.0”?
Um… no, it wasn’t, it was “Non-API changes I’d like to see in SDL 2.0”
Don’t know about you, but where I’m from, the work ‘like’ tends to
indicate a preference, not a demand or dictat.
Sorry Bob, you said at the top that you didn’t want to make this
personal, but the thing is, that’s exactly what you’ve done; you’ve made
it about what you think I know, not about the merits of my
comments/suggestions. Here’s a tip for you Bob: never write “Don’t take
this personally.” in anything, as if you are, it clearly IS personal!
I apologise to other users of the group if I seem somewhat vitriolic,
but you must understand that I do NOT suffer unjustified personal
attacks; treat me with dignity and respect and I will do the same to
you; attack me for ‘being something’ rather than what I say, and you can
expect a robust response.
FYI, I’m 27 years old and have ‘been around’ in many different
professional environments (some more-so than others!). When I started
working at Sony as a contractor, I was offered a permanent position
within 4 weeks of starting and I HAD TO EXPLAIN TO MY BOSS THAT I WAS
STILL A STUDENT! I’m no mug; I am CERTAINLY no child and resent anyone
who would patronise me or speak to me in a condescending manner.
If anyone has any comments on the substance of my original post, then
please do let me know.
Regards,
Eddy> On 3/10/08, Edward Cullen <eac203 at ecs.soton.ac.uk <mailto:eac203 at ecs.soton.ac.uk>> wrote:
