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

SDL Development
21

E. Wing wrote:

I would be interested in knowing, what specific things do people
dislike (or ‘hate’ as some have put it) about CMake. This has been an
on-and-off topic on the CMake list itself, but it would be nice to get
some opinions from those who are already not self-selected enough to
be on the CMake list.

Thanks,
Eric

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

In my experience so far (mostly small games and apps), CMake works well
in its actual functionality, but the scripting language that you use to
define CMakeLists is pretty obtuse and difficult to remember. I think
it would be much easier for people to stomach CMake if they could use an
existing scripting language or at least make the internal scripting
language more concise.

  • brian
22

I initially wrote to Eric directly, but have been thinking more on it
and my view can be best summed up as this:

The Make manual is more than a reference for Make - it is a guide on how
to create and manage a build system as a whole. If one understands how
to use Make, it should automatically make one better at
defining/managing build systems, no matter what tool(s) you use.

The danger of a front-end like CMake, is that it promotes ignorance;
there is a danger that users will not understand the underlying
principles of what they’re trying to achieve, simply doing what appears
most expedient.

As I indicated, this is more a religious view than a hard-and-fast
complaint against CMake… I think the same would actually apply to
Automake, because, as far as I can tell, there is nothing that Automake
can do that can’t be achieved by well-written Make files.

Autoconf is different, as this (ostensibly) only generates options,
which could be used without modifying the actual Makefiles.

This is related to my experience of learning to be a developer.

I have found that the best way to learn is to start with command-line
tools, building up one option/command at a time, in contrast to starting
with an IDE (like VS), which presents ALL the options/commands in one go.

Using the command line approach, I have found that I have a much
better understanding of what’s going on, understanding that is
transferred to other IDEs, tool-chains etc. Understanding that makes me
a better developer in general.

Incidentally, I don’t actually have anything against VS - I believe it’s
one of the better IDEs about (not perfect like…) - except for it being
Windows-centric, that is :wink:

Jitsu Love,

Eddy

E. Wing wrote:> I would be interested in knowing, what specific things do people

dislike (or ‘hate’ as some have put it) about CMake. This has been an
on-and-off topic on the CMake list itself, but it would be nice to get
some opinions from those who are already not self-selected enough to
be on the CMake list.

Thanks,
Eric

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

23

Ryan C. Gordon wrote:

Was autoconf unacceptable, too? Because it’s arguably the same thing as
CMake, minus a scripting language that may or may not suck more than
CMake’s scripting language, and it only generates for one type of build
system.

AFAIK autoconf only runs on UNIX-like systems, which makes it even less
suitable for my projects than CMake. (My primary development system
runs Windows XP and my preferred compiler is Microsoft Visual C++.)–
Rainer Deyke - rainerd at eldwood.com

24

I like Makefiles and am not particularly in favor of CMake (and I
realize you’re not pushing Makefiles as an absolute necessity), but in
my view it’s probably not the place of SDL to promote the learning of
the workings of build systems by “normal” SDL end users. I think the
major factor for consideration should be usability–the most people
being able to build SDL with the least amount of fuss (which could end
up being Makefiles, or maybe not).

I agree that people probably would learn a great deal more by being
forced to use Makefiles than other systems, but my point is that if
Makefiles are more cumbersome to maintain (and/or are not as convenient
for end users), it would make more sense to use another build system
rather than use Makefiles for the sake of forcing end users to educate
themselves about build systems.

Of course time spent on maintaining the build system is time taken away
from coding.

Summary: I think you’re right about Makefiles, but educating end users
of build systems shouldn’t be a more important factor than other issues
in the decision of which build system to use. IMHO.

ChazOn Wed, 2008-03-12 at 16:09 +0000, Edward Cullen wrote:

I initially wrote to Eric directly, but have been thinking more on it
and my view can be best summed up as this:

The Make manual is more than a reference for Make - it is a guide on how
to create and manage a build system as a whole. If one understands how
to use Make, it should automatically make one better at
defining/managing build systems, no matter what tool(s) you use.

The danger of a front-end like CMake, is that it promotes ignorance;
there is a danger that users will not understand the underlying
principles of what they’re trying to achieve, simply doing what appears
most expedient.

As I indicated, this is more a religious view than a hard-and-fast
complaint against CMake… I think the same would actually apply to
Automake, because, as far as I can tell, there is nothing that Automake
can do that can’t be achieved by well-written Make files.

Autoconf is different, as this (ostensibly) only generates options,
which could be used without modifying the actual Makefiles.

This is related to my experience of learning to be a developer.

I have found that the best way to learn is to start with command-line
tools, building up one option/command at a time, in contrast to starting
with an IDE (like VS), which presents ALL the options/commands in one go.

Using the command line approach, I have found that I have a much
better understanding of what’s going on, understanding that is
transferred to other IDEs, tool-chains etc. Understanding that makes me
a better developer in general.

Incidentally, I don’t actually have anything against VS - I believe it’s
one of the better IDEs about (not perfect like…) - except for it being
Windows-centric, that is :wink:

Jitsu Love,

Eddy

E. Wing wrote:

I would be interested in knowing, what specific things do people
dislike (or ‘hate’ as some have put it) about CMake. This has been an
on-and-off topic on the CMake list itself, but it would be nice to get
some opinions from those who are already not self-selected enough to
be on the CMake list.

Thanks,
Eric

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

25
  1. 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…

Interesting idea that I hadn’t considered. First things first though. :slight_smile:

I’ve never actually had to write an ABI. OTOH, I did supervise and revue
the writing of a big chunk of the SPARC64 ABI back in the early '90s when I
was working on a 64 bit port of X to the, at the time nonexisten,t SPARC64
architecture. In my opinion ABIs are not appropriate for libraries, and they
are not needed for writing plug in replacements. ABIs are appropriate for OS
interfaces and in some cases for code that is built into firmware. If you
should decide to build one take a look at SWIG and similar tools as a way of
generating it automatically from the existing .h files. Since the compiler
already generates an ABI for the library there is not much reason to
generate the document by hand.

Bob Pendleton

See ya!On 3/11/08, Sam Lantinga wrote:

    -Sam Lantinga, Lead Software Engineer, Blizzard Entertainment

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

–

±-------------------------------------+

26

You might be interested in BSDBuild (http://hypertriton.com/bsdbuild/).
Its “make” part is implemented as a make library, so your makefiles do
not need to be generated (unless you’re doing a concurrent build), and
they follow the traditional BSD style, so they are easy and efficient
to maintain. This would be a complete makefile for an application:

TOP=.
PROG=	foo
SRCS=	foo.c
MAN1=	foo.1
include ${TOP}/mk/build.prog.mk

BSDBuild can also generate configure scripts. Compilation of IDE project
files is supported if you have the premake utility installed. The feedback
I get is that it is overall less painful to use (and to learn) than the
GNU system.On Wed, Mar 12, 2008 at 11:19:22AM -0600, Charles McGarvey wrote:

I like Makefiles and am not particularly in favor of CMake (and I
realize you’re not pushing Makefiles as an absolute necessity), but in
my view it’s probably not the place of SDL to promote the learning of
the workings of build systems by “normal” SDL end users. I think the
major factor for consideration should be usability–the most people
being able to build SDL with the least amount of fuss (which could end
up being Makefiles, or maybe not).

I agree that people probably would learn a great deal more by being
forced to use Makefiles than other systems, but my point is that if
Makefiles are more cumbersome to maintain (and/or are not as convenient
for end users), it would make more sense to use another build system
rather than use Makefiles for the sake of forcing end users to educate
themselves about build systems.

Of course time spent on maintaining the build system is time taken away
from coding.

Summary: I think you’re right about Makefiles, but educating end users
of build systems shouldn’t be a more important factor than other issues
in the decision of which build system to use. IMHO.

Chaz

On Wed, 2008-03-12 at 16:09 +0000, Edward Cullen wrote:

I initially wrote to Eric directly, but have been thinking more on it
and my view can be best summed up as this:

The Make manual is more than a reference for Make - it is a guide on how
to create and manage a build system as a whole. If one understands how
to use Make, it should automatically make one better at
defining/managing build systems, no matter what tool(s) you use.

The danger of a front-end like CMake, is that it promotes ignorance;
there is a danger that users will not understand the underlying
principles of what they’re trying to achieve, simply doing what appears
most expedient.

As I indicated, this is more a religious view than a hard-and-fast
complaint against CMake… I think the same would actually apply to
Automake, because, as far as I can tell, there is nothing that Automake
can do that can’t be achieved by well-written Make files.

Autoconf is different, as this (ostensibly) only generates options,
which could be used without modifying the actual Makefiles.

This is related to my experience of learning to be a developer.

I have found that the best way to learn is to start with command-line
tools, building up one option/command at a time, in contrast to starting
with an IDE (like VS), which presents ALL the options/commands in one go.

Using the command line approach, I have found that I have a much
better understanding of what’s going on, understanding that is
transferred to other IDEs, tool-chains etc. Understanding that makes me
a better developer in general.

Incidentally, I don’t actually have anything against VS - I believe it’s
one of the better IDEs about (not perfect like…) - except for it being
Windows-centric, that is :wink:

Jitsu Love,

Eddy

E. Wing wrote:

I would be interested in knowing, what specific things do people
dislike (or ‘hate’ as some have put it) about CMake. This has been an
on-and-off topic on the CMake list itself, but it would be nice to get
some opinions from those who are already not self-selected enough to
be on the CMake list.

Thanks,
Eric

27

I’ve gotta agree. An ABI is for a complete system; SDL is mostly just a set of abstraction layers. It’s very good at what it does, but it’s not a complete system, by which I mean that you could no more build a complex, fully-functional game using SDL APIs and nothing else than you could build a house with nothing but studs. They provide a very important and useful framework, but they’re only one part of a larger system.> ----- Original Message -----

From: bob@pendleton.com (Bob Pendleton)

In my opinion ABIs are not appropriate for libraries, and they are not needed for writing plug in replacements.
ABIs are appropriate for OS interfaces and in some cases for code that is built into firmware. If you should decide
to build one take a look at SWIG and similar tools as a way of generating it automatically from the existing .h
files. Since the compiler already generates an ABI for the library there is not much reason to generate the
document by hand.