SDL_Config.h - Cross platform builds

SDL Development
1

Instead of throwing an error, and forcing the build to change over the files from SDL_config.h to SDL_config.h.default; why not simply:

SDL_config.h

Code:

/* Make sure that this isn’t included by Visual C++ */
#ifdef _MSC_VER
#include “SDL_config.h.default”
#else

//…

#endif /* _MSC_VER /
#endif / _SDL_config_h */

And maybe rename the config.h.default to something else, so it conforms to the naming standard of .h?[/code]

2

The problem is we can’t check any generated files into Mercurial.

So, if we check SDL_config.h in with your proposed change, then every time
it’s generated it’ll be listed as changed and will undoubtedly be
accidentally checked in with generated changes.

If we don’t generate SDL_config.h, then we need some way to tell that a file
generated by configure should be included instead of the default options.

I’m open to suggestions…On Tue, Feb 15, 2011 at 6:16 PM, Daniel wrote:

Instead of throwing an error, and forcing the build to change over the
files from SDL_config.h to SDL_config.h.default; why not simply:

SDL_config.h

Code:

/* Make sure that this isn’t included by Visual C++ */
#ifdef _MSC_VER
#include “SDL_config.h.default”
#else

//…

#endif /* _MSC_VER /
#endif / _SDL_config_h */

And maybe rename the config.h.default to something else, so it conforms to
the naming standard of .h?[/code]

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

–
-Sam Lantinga, Founder and CEO, Galaxy Gameworks

3

The problem is we can’t check any generated files into Mercurial.

So, if we check SDL_config.h in with your proposed change, then every time it’s generated it’ll be listed as changed and will undoubtedly be accidentally checked in with generated changes.

If we don’t generate SDL_config.h, then we need some way to tell that a file generated by configure should be included instead of the default options.

I’m open to suggestions…

I’m not sure I understand the precise circumstances, but you can certainly check generated
files into a repository.

The “conventional” way to build things is wrong. The correct way to build things
mandates that the repository and all files and directories therein are read only.

If you’re doing an “in-place” build, then the only correct way to make it happen
requires copying the repository as a first step.

In that case clobbering file in the repository with a generated one during the build
has no effect.

All major systems follow read-only repository model. It is also the only way
to build separate models simultaneously, for example a debug version
and a release version.

Ideally your build procedure is set up to avoid copying, for example by ensuring
complete separation of temporary files and outputs from inputs on the command lines
of all commands. eg you must use

gcc -c $REPO/src/xx.c -o $BUILDDIR/lib/x.o

etc etc. The proper way to build has a golden rule: the current directly must NEVER
be used for anything explicitly. (Recursive make is evil stupidity and should not be used :slight_smile:

This model also supports cross compilation, for example building windows executables on
Linux. Or in the gaming environment building for multiple game devices from a large
development machine with cross compilers.

Anyhow the easiest fix for an evil “in place” build model is to copy the whole repository
(excluding .svn files etc) to a nominated or defaulted location, cd into that, and then
proceed to build “as normal”. It’s easy to modify the config script to accept an option
which allows to specify the directory, or to calculate the build directory name from
parameters (such as platform name, debug options, etc). Or both.

If you actually WANT to then commit a generated file back to the repository you can
copy it back from the build to the repo image and then commit. It can’t happen by default,
which is what you want.

This is also vital for documentation where you have, say, doc.tex source and want
to also include doc.pdf and doc.html in the repo, which are generated, because not
all developers have the tools to generate these files.On 16/02/2011, at 2:17 PM, Sam Lantinga wrote:

–
john skaller
@john_skaller

4

Ah, you’re right, I am so used to building and testing in-place that I had
forgotten that. SDL of course does support configuring and building in a
separate directory from the repo and that is the correct way to do it.

Time to change my habits.

Thanks!On Wed, Feb 16, 2011 at 1:26 AM, john skaller <skaller at users.sourceforge.net wrote:

On 16/02/2011, at 2:17 PM, Sam Lantinga wrote:

The problem is we can’t check any generated files into Mercurial.

So, if we check SDL_config.h in with your proposed change, then every
time it’s generated it’ll be listed as changed and will undoubtedly be
accidentally checked in with generated changes.

If we don’t generate SDL_config.h, then we need some way to tell that a
file generated by configure should be included instead of the default
options.

I’m open to suggestions…

I’m not sure I understand the precise circumstances, but you can certainly
check generated
files into a repository.

The “conventional” way to build things is wrong. The correct way to build
things
mandates that the repository and all files and directories therein are read
only.

If you’re doing an “in-place” build, then the only correct way to make it
happen
requires copying the repository as a first step.

In that case clobbering file in the repository with a generated one during
the build
has no effect.

All major systems follow read-only repository model. It is also the only
way
to build separate models simultaneously, for example a debug version
and a release version.

Ideally your build procedure is set up to avoid copying, for example by
ensuring
complete separation of temporary files and outputs from inputs on the
command lines
of all commands. eg you must use

gcc -c $REPO/src/xx.c -o $BUILDDIR/lib/x.o

etc etc. The proper way to build has a golden rule: the current directly
must NEVER
be used for anything explicitly. (Recursive make is evil stupidity and
should not be used :slight_smile:

This model also supports cross compilation, for example building windows
executables on
Linux. Or in the gaming environment building for multiple game devices from
a large
development machine with cross compilers.

Anyhow the easiest fix for an evil “in place” build model is to copy the
whole repository
(excluding .svn files etc) to a nominated or defaulted location, cd into
that, and then
proceed to build “as normal”. It’s easy to modify the config script to
accept an option
which allows to specify the directory, or to calculate the build directory
name from
parameters (such as platform name, debug options, etc). Or both.

If you actually WANT to then commit a generated file back to the repository
you can
copy it back from the build to the repo image and then commit. It can’t
happen by default,
which is what you want.

This is also vital for documentation where you have, say, doc.tex source
and want
to also include doc.pdf and doc.html in the repo, which are generated,
because not
all developers have the tools to generate these files.

–
john skaller
skaller at users.sourceforge.net

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

–
-Sam Lantinga, Founder and CEO, Galaxy Gameworks

5

Okay, in theory you can now do a fresh checkout of SDL and build cleanly on
it without any file copying steps.

If you’re using UNIX style configure, the cleanest way to do that is to
configure and build from a separate directory. If you forget, it’s no big
deal, you’ll just have to remember not to commit include/SDL_config.h and
include/SDL_revision.h

Woo, thanks!On Wed, Feb 16, 2011 at 1:46 AM, Sam Lantinga <@slouken> wrote:

Ah, you’re right, I am so used to building and testing in-place that I had
forgotten that. SDL of course does support configuring and building in a
separate directory from the repo and that is the correct way to do it.

Time to change my habits.

Thanks!

On Wed, Feb 16, 2011 at 1:26 AM, john skaller < skaller at users.sourceforge.net> wrote:

On 16/02/2011, at 2:17 PM, Sam Lantinga wrote:

The problem is we can’t check any generated files into Mercurial.

So, if we check SDL_config.h in with your proposed change, then every
time it’s generated it’ll be listed as changed and will undoubtedly be
accidentally checked in with generated changes.

If we don’t generate SDL_config.h, then we need some way to tell that a
file generated by configure should be included instead of the default
options.

I’m open to suggestions…

I’m not sure I understand the precise circumstances, but you can certainly
check generated
files into a repository.

The “conventional” way to build things is wrong. The correct way to build
things
mandates that the repository and all files and directories therein are
read only.

If you’re doing an “in-place” build, then the only correct way to make it
happen
requires copying the repository as a first step.

In that case clobbering file in the repository with a generated one during
the build
has no effect.

All major systems follow read-only repository model. It is also the only
way
to build separate models simultaneously, for example a debug version
and a release version.

Ideally your build procedure is set up to avoid copying, for example by
ensuring
complete separation of temporary files and outputs from inputs on the
command lines
of all commands. eg you must use

gcc -c $REPO/src/xx.c -o $BUILDDIR/lib/x.o

etc etc. The proper way to build has a golden rule: the current directly
must NEVER
be used for anything explicitly. (Recursive make is evil stupidity and
should not be used :slight_smile:

This model also supports cross compilation, for example building windows
executables on
Linux. Or in the gaming environment building for multiple game devices
from a large
development machine with cross compilers.

Anyhow the easiest fix for an evil “in place” build model is to copy the
whole repository
(excluding .svn files etc) to a nominated or defaulted location, cd into
that, and then
proceed to build “as normal”. It’s easy to modify the config script to
accept an option
which allows to specify the directory, or to calculate the build directory
name from
parameters (such as platform name, debug options, etc). Or both.

If you actually WANT to then commit a generated file back to the
repository you can
copy it back from the build to the repo image and then commit. It can’t
happen by default,
which is what you want.

This is also vital for documentation where you have, say, doc.tex source
and want
to also include doc.pdf and doc.html in the repo, which are generated,
because not
all developers have the tools to generate these files.

–
john skaller
skaller at users.sourceforge.net

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

–
-Sam Lantinga, Founder and CEO, Galaxy Gameworks

–
-Sam Lantinga, Founder and CEO, Galaxy Gameworks

6

Okay, in theory you can now do a fresh checkout of SDL and build cleanly on it without any file copying steps.

Er … how? Just say $REPO/configure or something?

If you’re using UNIX style configure, the cleanest way to do that is to configure and build from a separate directory. If you forget, it’s no big deal, you’ll just have to remember not to commit include/SDL_config.h and include/SDL_revision.h

Well, SDL_config.h has to be copied doesn’t it?

There’s a general problem here, which all build systems have to cope with, and for which
there’s no easy solution and no generally accepted solution either.

This is the problem which I will call “user config data problem” err … that’s long so
how about uconf for short?

The problem arises as follows: every user/platform has certain “personal” properties
such as “weird locations of libraries”. Of course there are others. The question is:
how do you establish those properties?

Normally a build system does this: it comes with some predefined properties,
and it runs a configuration step to “guess” at some more of them, for example
by searching for libraries.

But still that’s not enough. The problem is the user cannot just edit the generated
config data because it gets clobbered by the next checkout. And it gets lost
if you do another separate checkout.

What Felix does is this … note config data is a set of files:

a) default config in repository copied to config target
b) config finds basic platform type
c) copy general platform specific stuff to config target
d) config searches for more stuff and writes to the config target
e) config copies stuff from $HOME/.felix/config

I’m also thinking of copying more stuff from an installed location.
[On Unix for system stuff this is usually done from /etc/THING/config or so,
for SDL you might use instead sdl-config --config or something]

Step (e) ensures user config data is never lost. It has the downside
that it is universal (applied to all builds, so if you’re building for two
platforms it is not so useful).

BTW: the existing config works fine for me at the moment.
I just thought I’d mention this problem because SDL is being built
for a LOT of platforms and probably needs cross-compilation support
and that stuff is notoriously hard. So I’m making my contribution and
also hoping to learn of any other techniques developers might know.
SDL basically doesn’t do any real work: it’s an abstraction layer.
My product is in many ways similar (its actually a cross-cross
compiler so that is even more fun … :)On 16/02/2011, at 9:39 PM, Sam Lantinga wrote:

–
john skaller
@john_skaller

7

Okay, in theory you can now do a fresh checkout of SDL and build cleanly
on it without any file copying steps.

Er … how? Just say $REPO/configure or something?

Yep. :)On Wed, Feb 16, 2011 at 4:58 AM, john skaller <skaller at users.sourceforge.net wrote:

On 16/02/2011, at 9:39 PM, Sam Lantinga wrote:

–
-Sam Lantinga, Founder and CEO, Galaxy Gameworks