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