Makefiles vs autoconf for SDL (Was: Re: Autotoold)

SDL Development
1

“Mark K. Kim” wrote:

Okay… I feel really behind for writing my own makefiles… I’ve been
putting off learning automake/autoconf because I haven’t had the time to
learn all the test conditions and stuff.

Don’t use autoconf unless you have a good reason to. For SDL games,
autoconf is not as important as with free-standing games since SDL already
contains most of the platform-independent stuff. Basically all that’s
needed is to say where SDL can be found; sdl-config helps a great deal.

A well-written and commented Makefile can be simple and easy to use. I
generally have a lot more trouble with badly written configure scripts. As
an example, of the winning entries in the recent contest, the by far
easiest to build and run was Bill Kendrick’s Vectoroids, which had a
single, short Makefile.

And this was on a plain normal RedHat box; on a more exotic system, the
difference would have been even greater.

2

Es schrieb Mattias Engdeg?rd:

“Mark K. Kim” wrote:

Okay… I feel really behind for writing my own makefiles… I’ve been
putting off learning automake/autoconf because I haven’t had the time to
learn all the test conditions and stuff.

Don’t use autoconf unless you have a good reason to. For SDL games,
autoconf is not as important as with free-standing games since SDL already
contains most of the platform-independent stuff. Basically all that’s
needed is to say where SDL can be found; sdl-config helps a great deal.

A well-written and commented Makefile can be simple and easy to use. I
generally have a lot more trouble with badly written configure scripts. As
an example, of the winning entries in the recent contest, the by far
easiest to build and run was Bill Kendrick’s Vectoroids, which had a
single, short Makefile.

And this was on a plain normal RedHat box; on a more exotic system, the
difference would have been even greater.

If you only need sdl and libc, you’re fine - and this is the most
portable setup of course. However, most programs find one or two
platform dependencies, and that case, I do see far too many developers
being lazy and goint to ask other people to “edit the makefile”.

However, autoconf is not that complicated, cp Makefile Makefile.in,
mark every editable entry as @EDITTABLE@ and haven AC_SUBST for it in
a configure-script - a few minutes extra that saves a lot of headaches
for people who do not know much about the program they happen to have.

Therefore: use autoconf unless you have a good reason not to, like
ensuring to limit dependencies to sdl and libc.

cheers,
– guido http://freespace.sf.net/guidod
GCS/E/S/P C++$++++ ULHS L++w- N++@ d(±) s+a- r+@>+++ y++ 5++X- (geekcode)

3

A well-written and commented Makefile can be simple and easy to use. I
generally have a lot more trouble with badly written configure scripts. As
an example, of the winning entries in the recent contest, the by far
easiest to build and run was Bill Kendrick’s Vectoroids, which had a
single, short Makefile.

And this was on a plain normal RedHat box; on a more exotic system, the
difference would have been even greater.

So, Bill was lucky. The contest rules specifically said that it should be
easy to build. It stated what libraries were available, but nothing
about what distribution. I have tried to compile “simple Makefiles” that
would work on RH, but break on debian and vice versa. A properly written
autotools setup will work on both.

Another thing; if you use autoconf and automake, peple can look at your
makefile.am and configure.in, which for many projects are very simple, and
think; “OK, nothing bad going on in here, I can bootstrap the code, and I
will trust both make, make install and maybe even make uninstall to work”.

For many “simple makefiles” is is just hard to tell what actions will be
carried out during install, where files will end up, and so on. (Yes, you
can do a make --dry-run install, but it is just not good enough…)

Mads

P.S. My own entry was rather complicated to build, because I only to late
realised that Python did not link dynamically - so, I had to include a
script that automatically converted the static python lib to a .so - also
based on autoconf. But, that was a consequence of the rules, not the
approach.On Thu, 24 Jan 2002, Mattias Engdegard wrote:

–
Mads Bondo Dydensborg. @Mads_Bondo_Dydensbor
The infamous Melissa virus, Explore.zip, VBS/Bubbleboy, X97M/Papa, ILOVEYOU
and MORELOVE viruses all used the Outlook address book to spread themselves.

4

Guido Draheim wrote:

If you only need sdl and libc, you’re fine - and this is the most
portable setup of course. However, most programs find one or two
platform dependencies, and that case, I do see far too many developers
being lazy and goint to ask other people to “edit the makefile”.

You miss the point. A well-written Makefile is supposed to be edited, and
this is not difficult. If you get a mental block whenever it says “edit
the Makefile”, perhaps you should not attempt to build from source at all.

I prefer by far editing a well-written and commented Makefile to
fiddling with configure options, writing 2-300 characters long configure
invocations, waiting for the slow configure script to terminate, realise
it still didn’t find the right version of libfoo, trying new combinations
of variables, and finally — and mind you, this is not unusual —
editing the auto-generated Makefiles by hand, only to have it destroyed
whenever I need to re-run configure.

Trust me, I’ve done the above more times than I can remember. A well-written
configure.in is quite rare, especially when coming from amateur game
developers. If you find otherwise, you’ve been living a sheltered life.

However, autoconf is not that complicated

It is a lot more complicated than Make, but that isn’t the point. The
point is that most people only have their own system to try their
build system on, and their friends are likely to have similar systems.

This means that their configure scripts may very well not work on
systems where libs are in slightly different location, the compiler is
not gcc and requires completely different flags, the user has no
superuser privs, the OS is not linux, or the user prefers not
installing things where the original author though would be a good
place.

The conclusion remains. Don’t use autoconf unless you have good reasons
to, and you really know what you are doing

5

I think we may have found the reason for disagreeing - I compile my
software on quite some systems, different systems, different setups,
and I do not like to maintain a dozen makefiles edited from an
original scheme to cope with the local differences around. Therefore,
I put the intelligence into a “configure” script, and I do not
hesitate to add checks that are only valid for the system that I
happen to work on - the canned ac-macros give me a lot of help to
get away with the usual setup in the different systems, the
experience of lots of other people and their system has been folded
in over time.

What’s more is updating software from source - if you need to grab
out an editor for every update, one will get to be a very busy
person - it’s far easier to memorize some configure-options and
let the configure-script do the rest, possibly different things
for the updated software - specifying prefix-paths is a way of
abstraction over the actual way the software gets compiled.

The conclusion remains, if you want to write portable software,
memorize the difference you happen to meet in a configure script,
it will make the life of another person easier, since he might
only change just one thing, and not a dozen things.

cheers, guido
P.S. to be fair, let me notify you of one of my projects where I try
to memorize the experience of others in canned ac-macros ready to
be reused for my configure scirpts: http://ac-archive.sf.net

Es schrieb Mattias Engdeg?rd:>

Guido Draheim wrote:

If you only need sdl and libc, you’re fine - and this is the most
portable setup of course. However, most programs find one or two
platform dependencies, and that case, I do see far too many developers
being lazy and goint to ask other people to “edit the makefile”.

You miss the point. A well-written Makefile is supposed to be edited, and
this is not difficult. If you get a mental block whenever it says “edit
the Makefile”, perhaps you should not attempt to build from source at all.

I prefer by far editing a well-written and commented Makefile to
fiddling with configure options, writing 2-300 characters long configure
invocations, waiting for the slow configure script to terminate, realise
it still didn’t find the right version of libfoo, trying new combinations
of variables, and finally — and mind you, this is not unusual —
editing the auto-generated Makefiles by hand, only to have it destroyed
whenever I need to re-run configure.

Trust me, I’ve done the above more times than I can remember. A well-written
configure.in is quite rare, especially when coming from amateur game
developers. If you find otherwise, you’ve been living a sheltered life.

However, autoconf is not that complicated

It is a lot more complicated than Make, but that isn’t the point. The
point is that most people only have their own system to try their
build system on, and their friends are likely to have similar systems.

This means that their configure scripts may very well not work on
systems where libs are in slightly different location, the compiler is
not gcc and requires completely different flags, the user has no
superuser privs, the OS is not linux, or the user prefers not
installing things where the original author though would be a good
place.

The conclusion remains. Don’t use autoconf unless you have good reasons
to, and you really know what you are doing

6

Guido Draheim wrote:

I think we may have found the reason for disagreeing - I compile my
software on quite some systems, different systems, different setups,

You are not a typical developer then, and while I have no problem
creating working autoconf script myself I do not advice people without
porting experience to do so.

The conclusion remains, if you want to write portable software,
memorize the difference you happen to meet in a configure script,
it will make the life of another person easier, since he might
only change just one thing, and not a dozen things.

I think you will learn that is neither a necessary nor sufficient condition
for writing portable software.

To get this thread more firmly ontopic:

We would benefit a lot more from a standard way of configuring SDL games;
be it a pre-written autoconf template, a well-crafted Makefile or perhaps
another mechanism. Ideally it should be able to generate project files
for the standard win32/MacOS environments as well. It should take an
effort to make a bad build system. Telling people to use autoconf is
NOT the answer

7

Es schrieb Mattias Engdeg?rd:

Guido Draheim wrote:

I think we may have found the reason for disagreeing - I compile my
software on quite some systems, different systems, different setups,

You are not a typical developer then, and while I have no problem
creating working autoconf script myself I do not advice people without
porting experience to do so.

well, it still needs to learn what makefiles and shell-scripts are,
for the easytodo programmers, it is much better to take advantage
of an IDE that guides the developer - most IDEs can even write a
makefile for off-site compiling, some even automake stuff, IIRC.

The conclusion remains, if you want to write portable software,
memorize the difference you happen to meet in a configure script,
it will make the life of another person easier, since he might
only change just one thing, and not a dozen things.

I think you will learn that is neither a necessary nor sufficient condition
for writing portable software.

To get this thread more firmly ontopic:

We would benefit a lot more from a standard way of configuring SDL games;
be it a pre-written autoconf template, a well-crafted Makefile or perhaps
another mechanism. Ideally it should be able to generate project files
for the standard win32/MacOS environments as well. It should take an
effort to make a bad build system. Telling people to use autoconf is
NOT the answer

sorry for ending up off-topic, I was specifically opposing you
for counselling not to learn autoconf unless there is a reason to,
while I still think that things should be the other way round - if
you know makefiles, don’t hesitate to take advantage of autoconf
(and best add the libtool/automake pair) - don’t hesitate to use it
on the very first occasion that you happen to see problems between
two platforms you happen to see your software being compiled on.

Of course, it is neither necessary nor sufficient condition to write
portable software, it is a fine tool to help lifting the burden and
take away much of the work that would usually need to be done to port
software. There are other tools, possibly homegrown stuff (see the
QT toolkit and their configuration engine), which are often better
suited for the actual piece of software. However, such homegrown
portability stuff needs to get developed in the first place, and the
many years of experience in autotools (autoconf/libtool/automake)
will certainly be the best option for everyone who wants to add
an automation tool to his software to help in portability issues.

Yes, documenting a standard way for creating SDL games would certainly
help new developers to get away with SDL, especially if the just
want to write games and not distribution tarballs and rpm packages,
The SDL is now the de-facto standard lowlevel gaming toolkit around,
and it has indeed spawned quite some efforts to help jumpstart people
in creating sdl games - I refer to the IDEs where it becomes more
and more popular to have a newproject wizard that not only knows
about “kde program” or “gtk program” but also “sdl program”. The
relations between all these parts? well, the sdl mailing list :wink:

Providing an extra tool with SDL? I’m not sure, there are a lot
of things going on in the autoconf world about automatic tools,
but ADL (Alexandre Duret-Lutz, also subscribed to this list) might
be better informed if that could even get modified for a customized
version for SDL, which I would find the best way to handle things.

cheers,
– guido http://freespace.sf.net/guidod
GCS/E/S/P C++$++++ ULHS L++w- N++@ d(±) s+a- r+@>+++ y++ 5++X- (geekcode)

8

To get this thread more firmly ontopic:

We would benefit a lot more from a standard way of configuring SDL games;
be it a pre-written autoconf template, a well-crafted Makefile or perhaps
another mechanism. Ideally it should be able to generate project files
for the standard win32/MacOS environments as well. It should take an
effort to make a bad build system. Telling people to use autoconf is
NOT the answer

Do a majority of SDL applications have enough in common to make this
wirthwhile? You said before (and I agree) that SDL (sdl-config) takes
care of a lot of the nastiness. That may be as generic as you can get,
including all that’s needed for the basic/common/whatever SDL app. Are
there other commonalities?

And on the topic of autotools vs. plain makefile, I think, as with
everything else, it depends on what you’re trying to do. Neither autoconf
nor automake is a cure-all. Given a problem, each person has to decided
whether or not make, autoconf, automake, or any combination therein
solves it.

DaveOn Thu, 24 Jan 2002, Mattias Engdegard wrote:

–

David MacCormack
@David_MacCormack

In the land of Redmond, where the Windows lie.
One OS to rule them all, One OS to find them,
One OS to bring them all and in the darkness bind them.
In the land of Redmond, where the Windows lie.

9

Es schrieb David MacCormack:

To get this thread more firmly ontopic:

We would benefit a lot more from a standard way of configuring SDL games;
be it a pre-written autoconf template, a well-crafted Makefile or perhaps
another mechanism. Ideally it should be able to generate project files
for the standard win32/MacOS environments as well. It should take an
effort to make a bad build system. Telling people to use autoconf is
NOT the answer

Do a majority of SDL applications have enough in common to make this
wirthwhile? You said before (and I agree) that SDL (sdl-config) takes
care of a lot of the nastiness. That may be as generic as you can get,
including all that’s needed for the basic/common/whatever SDL app. Are
there other commonalities?

And on the topic of autotools vs. plain makefile, I think, as with
everything else, it depends on what you’re trying to do. Neither autoconf
nor automake is a cure-all. Given a problem, each person has to decided
whether or not make, autoconf, automake, or any combination therein
solves it.

agreed - and a good final word.

– guido http://freespace.sf.net/guidod
GCS/E/S/P C++$++++ ULHS L++w- N++@ d(±) s+a- r+@>+++ y++ 5++X- (geekcode)> On Thu, 24 Jan 2002, Mattias Engdegard wrote:

10

David MacCormack wrote:

Do a majority of SDL applications have enough in common to make this
wirthwhile? You said before (and I agree) that SDL (sdl-config) takes
care of a lot of the nastiness. That may be as generic as you can get,
including all that’s needed for the basic/common/whatever SDL app. Are
there other commonalities?

Perhaps a uniform way of specifying where to install the game (executable
and data), and where to store things like settings and scores.
This is apparently difficult since so many people get it wrong :slight_smile:

11

“Guido” == Guido Draheim writes:

Guido> Es schrieb Mattias Engdeg?rd:

[…]

The conclusion remains, if you want to write portable software,
memorize the difference you happen to meet in a configure script,
it will make the life of another person easier, since he might
only change just one thing, and not a dozen things.

I think you will learn that is neither a necessary nor sufficient condition
for writing portable software.

True. ./configure scripts will only probe your system for
various flaw or features and configure your package accordingly.
Writing portable software using the hints provided by
./configure is still the burden of the programmer.

However, Autoconf helps writing portable software, because it
provides easy ways to check for features instead of checking
for some host-specific cpp macros in the source: e.g. #ifdef
linux. Host-specific macros aren’t always enough, and the day
you want to compile your program on a new system you need to
add an extra layer of #ifdef.

Actually SDL’s own configure is not a good exemple of configure
(wrt to Autoconf’ philosophy) because it checks whether it knows
the host type before checking for features. I’m not meaning the
converse is possible, but actually this prevents SDL from being
build on an unknown system (a portable library ought to figure
that this system as an X library and a some threading library,
and setup itself to use that automatically).

(Aside: all $target' in SDL's configure should be$host’.)

To get this thread more firmly ontopic:

We would benefit a lot more from a standard way of configuring SDL games;
be it a pre-written autoconf template, a well-crafted Makefile or perhaps
another mechanism. Ideally it should be able to generate project files
for the standard win32/MacOS environments as well. It should take an
effort to make a bad build system. Telling people to use autoconf is
NOT the answer

Autoconf and Automake are too much Unix-oriented. However if
you provide them with some limited Unixish environment you can
use the resulting configure and Makefile’s. Some people have
been using them under Win with MingW32 or Cygwin, under BeOS,
MacOS/X, or OS/2. Somewhere (don’t ask me where) there is even
a script that will act like gcc, but turn all the options into
the MSVC equivalent and call this compiler, so you can use it
with regular Automake Makefiles.

[…]–
Alexandre Duret-Lutz

12

Alexandre Duret-Lutz <duret_g at lrde.epita.fr> wrote:

Actually SDL’s own configure is not a good exemple of configure
(wrt to Autoconf’ philosophy) because it checks whether it knows
the host type before checking for features.

this is a known problem. SDL’s build system is being rewritten for 1.3

13

David MacCormack wrote:

Do a majority of SDL applications have enough in common to make this
wirthwhile? You said before (and I agree) that SDL (sdl-config) takes
care of a lot of the nastiness. That may be as generic as you can
get, including all that’s needed for the basic/common/whatever SDL
app. Are there other commonalities?

Perhaps a uniform way of specifying where to install the game
(executable and data), and where to store things like settings and
scores.

Yep, that would be very nice.

This is apparently difficult since so many people get it wrong
:slight_smile:

In fact, it’s very difficult, unless you know the details about every
OS that SDL supports. They all do it in different ways, and
autoconf/automake won’t help much, except for some of the Un*x-like
systems.

And then we have all these Linux distros, of which effectively none
follow any real standard… heh

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Thursday 24 January 2002 20:02, Mattias Engdeg?rd wrote: