Building, deployment and system directories

A while ago, I asked about how to handle data directories and directories for
configuration and highscore files across different platforms. Since then I’ve
had a look at fnkdat but ultimately decided to implement the necessary
functions myself (I figure I’ll have an easier job maintaining my library
this way).

However, during implementation, I’ve begun to worry about some other related
topics. First, my game sometimes creates directories. Eg. when writing the
highscore file to /usr/share/games/mygame, it creates the highscore file if
it doesn’t already exist. But that of course makes the current user the owner
of this file, whereas at least Debian seems to expect the file to be owned by
root:games. Should I let my installer create the file and then not replace it
with a new file when saving the highscores, but opening and overwriting the
existing one? Or am I overlooking some obvious and simpler solution?

Secondly, if my game always looks for its data files
in /usr/share/games/mygame, I have to copy them there after each build (yeah,
I could create a symbolic link, but then I’d have to delete that when trying
to actually install the thing after testing). My problem at this point is
mostly a design decision: I could implement a “testing” flag which tells the
app to look in a local subdir instead of the system dir, but then I’d always
have to recompile without that flag for a deployable version. I could have
the app always look in the current directory first, but that could lead to
unexpected results, obviously. Is there any established pattern for dealing
with this?

Thirdly, I’m wondering about the actual deployment. So far, I use Scons for
compilation. On Linux, I do both native compilation and cross-compilation
(mingw) for win32. I have a makefile providing separate targets which simply
calls scons, so I can build comfortably from KDevelop. When building for
win32, I also automatically create an NSIS installer, but so far, I don’t do
any deployment for Linux.

I will probably release the final game under some open source license, but
until I decide on a license, I’d still like to deploy the beta binary for
Linux systems. I guess before building debs and rpms, I should create some
less distribution-specific, shell-based way to install the thing, for people
who don’t want to use packages. But what would be the common way to do
this… a simple shell script that copies my files to the correct locations?
A makefile with just an install target? Or is their some simple (!) way to
create shell-based binary distributions, rpms and debs with one single tool?

Sorry for rambling on for so long about this, but I can’t seem to find any
simple answers to these questions just through Google. (And I’m sure I still
forgot one or two things I also wanted to ask…)

Thx in advance,
Marian.–
Hofstadter’s law: “It always takes longer than you think, even when you take
account of Hofstadter’s law”.

You might consider Hamster for the build system. It’s basically “SCons
in Lua”, so the concepts and API should be familiar to you. But… Lua
is much smaller build dependency than Python, and Hamster can work
either with ‘real’ SCons as the backbone, or create Makefiles
on-the-fly. So, in case you’re willing to Python->Lua convert yours
SCons scripts, that’d be fine.

Publishing Hamster in fink (OS X) packaging is submitted, and Debian
release will be the next. That means, you could simply declare
"BuildDepends: hamster" (that’s how fink does, at least). Of course,
you may do the same for SCons, but that will mean users not having (a
certain version of?) Python will be in front of a major download, just
to get your program compiled.

All in all, I do enjoy SCons, don’t get me wrong. It’s only… a bit
heavy, and includes the Kitchen Sink™ :slight_smile:

Look here: http://www.sci.fi/~abisoft/hamster

30.4.2005 kello 23:03, Marian Schedenig kirjoitti:

A while ago, I asked about how to handle data directories and
directories for> configuration and highscore files across different platforms. Since

then I’ve
had a look at fnkdat but ultimately decided to implement the necessary
functions myself (I figure I’ll have an easier job maintaining my
library
this way).

However, during implementation, I’ve begun to worry about some other
related
topics. First, my game sometimes creates directories. Eg. when writing
the
highscore file to /usr/share/games/mygame, it creates the highscore
file if
it doesn’t already exist. But that of course makes the current user
the owner
of this file, whereas at least Debian seems to expect the file to be
owned by
root:games. Should I let my installer create the file and then not
replace it
with a new file when saving the highscores, but opening and
overwriting the
existing one? Or am I overlooking some obvious and simpler solution?

Secondly, if my game always looks for its data files
in /usr/share/games/mygame, I have to copy them there after each build
(yeah,
I could create a symbolic link, but then I’d have to delete that when
trying
to actually install the thing after testing). My problem at this point
is
mostly a design decision: I could implement a “testing” flag which
tells the
app to look in a local subdir instead of the system dir, but then I’d
always
have to recompile without that flag for a deployable version. I could
have
the app always look in the current directory first, but that could
lead to
unexpected results, obviously. Is there any established pattern for
dealing
with this?

Thirdly, I’m wondering about the actual deployment. So far, I use
Scons for
compilation. On Linux, I do both native compilation and
cross-compilation
(mingw) for win32. I have a makefile providing separate targets which
simply
calls scons, so I can build comfortably from KDevelop. When building
for
win32, I also automatically create an NSIS installer, but so far, I
don’t do
any deployment for Linux.

I will probably release the final game under some open source license,
but
until I decide on a license, I’d still like to deploy the beta binary
for
Linux systems. I guess before building debs and rpms, I should create
some
less distribution-specific, shell-based way to install the thing, for
people
who don’t want to use packages. But what would be the common way to do
this… a simple shell script that copies my files to the correct
locations?
A makefile with just an install target? Or is their some simple (!)
way to
create shell-based binary distributions, rpms and debs with one single
tool?

Sorry for rambling on for so long about this, but I can’t seem to find
any
simple answers to these questions just through Google. (And I’m sure I
still
forgot one or two things I also wanted to ask…)

Thx in advance,
Marian.


Hofstadter’s law: “It always takes longer than you think, even when
you take
account of Hofstadter’s law”.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Quoth Marian Schedenig , on 2005-04-30 22:03:15 +0200:

A while ago, I asked about how to handle data directories and directories for
configuration and highscore files across different platforms. Since then I’ve
had a look at fnkdat but ultimately decided to implement the necessary
functions myself (I figure I’ll have an easier job maintaining my library
this way).

Just a note – you might want to look at PhysicsFS
http://www.icculus.org/physfs/, if it hasn’t been suggested already.
I’m not sure if this does exactly what you want, but it tries to
provide reasonably portable filesystem operations for that sort of
purpose, including sane search paths to some degree.

—> Drake Wilson
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050430/4e1b70e0/attachment.pgp

You might consider Hamster for the build system. It’s basically
"SCons in Lua", so the concepts and API should be familiar to you.
But… Lua is much smaller build dependency than Python, and Hamster
can work either with ‘real’ SCons as the backbone, or create
Makefiles on-the-fly. So, in case you’re willing to Python->Lua
convert yours SCons scripts, that’d be fine.

Smaller build dependency than Python, on a platform where Python has
been included for the past three major versions and Lua still isn’t?

Publishing Hamster in fink (OS X) packaging is submitted, and
Debian release will be the next. That means, you could simply
declare “BuildDepends: hamster” (that’s how fink does, at least).
Of course, you may do the same for SCons, but that will mean users
not having (a certain version of?) Python will be in front of a
major download, just to get your program compiled.

Last I checked, SCons required Python 1.5.2. The oldest version of
Python that ever shipped with Mac OS X is well beyond that; it’s not
even reasonably possible to compile a version of Python that old on
Mac OS X!

Mac OS X 10.2 - Python 2.2.0
Mac OS X 10.3 - Python 2.3.0
Mac OS X 10.4 - Python 2.3.5

Python 2.4.1 is current, and is readily available as a framework for
Mac OS X 10.3+.

-bobOn Apr 30, 2005, at 7:41 PM, Asko Kauppi wrote:

So… then having SCons as a build dependency should be no problem?

1.5.2005 kello 03:27, Bob Ippolito kirjoitti:> On Apr 30, 2005, at 7:41 PM, Asko Kauppi wrote:

You might consider Hamster for the build system. It’s basically
"SCons in Lua", so the concepts and API should be familiar to you.
But… Lua is much smaller build dependency than Python, and Hamster
can work either with ‘real’ SCons as the backbone, or create
Makefiles on-the-fly. So, in case you’re willing to Python->Lua
convert yours SCons scripts, that’d be fine.

Smaller build dependency than Python, on a platform where Python has
been included for the past three major versions and Lua still isn’t?

Publishing Hamster in fink (OS X) packaging is submitted, and Debian
release will be the next. That means, you could simply declare
"BuildDepends: hamster" (that’s how fink does, at least). Of course,
you may do the same for SCons, but that will mean users not having (a
certain version of?) Python will be in front of a major download,
just to get your program compiled.

Last I checked, SCons required Python 1.5.2. The oldest version of
Python that ever shipped with Mac OS X is well beyond that; it’s not
even reasonably possible to compile a version of Python that old on
Mac OS X!

Mac OS X 10.2 - Python 2.2.0
Mac OS X 10.3 - Python 2.3.0
Mac OS X 10.4 - Python 2.3.5

Python 2.4.1 is current, and is readily available as a framework for
Mac OS X 10.3+.

-bob

Certainly less of a problem than Hamster, which would be two
(obscure) build dependencies.

SCons is only one dependency (since Python is already there), and is
not nearly as obscure. In fact, a Python interpreter compatible with
SCons should be pre-installed just about everywhere. Most of the
major Linux distributions, Mac OS X, and even some Windows OEMs, ship
with tools written in Python, so you’re going to have it around
whether you asked for it or not.

-bobOn Apr 30, 2005, at 10:34 PM, Asko Kauppi wrote:

So… then having SCons as a build dependency should be no problem?

1.5.2005 kello 03:27, Bob Ippolito kirjoitti:

On Apr 30, 2005, at 7:41 PM, Asko Kauppi wrote:

You might consider Hamster for the build system. It’s basically
"SCons in Lua", so the concepts and API should be familiar to
you. But… Lua is much smaller build dependency than Python, and
Hamster can work either with ‘real’ SCons as the backbone, or
create Makefiles on-the-fly. So, in case you’re willing to Python-

Lua convert yours SCons scripts, that’d be fine.

Smaller build dependency than Python, on a platform where Python
has been included for the past three major versions and Lua still
isn’t?

Publishing Hamster in fink (OS X) packaging is submitted, and
Debian release will be the next. That means, you could simply
declare “BuildDepends: hamster” (that’s how fink does, at
least). Of course, you may do the same for SCons, but that will
mean users not having (a certain version of?) Python will be in
front of a major download, just to get your program compiled.

Last I checked, SCons required Python 1.5.2. The oldest version
of Python that ever shipped with Mac OS X is well beyond that;
it’s not even reasonably possible to compile a version of Python
that old on Mac OS X!

Mac OS X 10.2 - Python 2.2.0
Mac OS X 10.3 - Python 2.3.0
Mac OS X 10.4 - Python 2.3.5

Python 2.4.1 is current, and is readily available as a framework
for Mac OS X 10.3+.

-bob


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

I’ll have a look at it, mostly for the transparent archive handling (something
which will certainly be good to have sooner or later). It doesn’t really seem
to help me with deciding what directories to use for my files on each
platform, so my original question still stands. :slight_smile:

Thanks,
Marian.On Sunday 01 May 2005 02:10, Drake Wilson wrote:

Just a note – you might want to look at PhysicsFS
http://www.icculus.org/physfs/, if it hasn’t been suggested already.
I’m not sure if this does exactly what you want, but it tries to
provide reasonably portable filesystem operations for that sort of
purpose, including sane search paths to some degree.


Hofstadter’s law: “It always takes longer than you think, even when you take
account of Hofstadter’s law”.

If you would look at the API of physfs you would notice some interesting
functions… :)On Monday 02 May 2005 02:35, Marian Schedenig wrote:

On Sunday 01 May 2005 02:10, Drake Wilson wrote:

Just a note – you might want to look at PhysicsFS
http://www.icculus.org/physfs/, if it hasn’t been suggested
already. I’m not sure if this does exactly what you want, but it
tries to provide reasonably portable filesystem operations for that
sort of purpose, including sane search paths to some degree.

I’ll have a look at it, mostly for the transparent archive handling
(something which will certainly be good to have sooner or later). It
doesn’t really seem to help me with deciding what directories to use
for my files on each platform, so my original question still stands.
:slight_smile:

D’oh, indeed. I must have overlooked those. I’ll have a closer look soon.

Thx a lot,
Marian.On Tuesday 10 May 2005 12:03, Sami N??t?nen wrote:

If you would look at the API of physfs you would notice some interesting
functions… :slight_smile:


Hofstadter’s law: “It always takes longer than you think, even when you take
account of Hofstadter’s law”.