SDL branch: Naming the executable

[a-nikolaev]

To build the graphical version:

make SDL=1

(i.e. the variable SDL must be defined)

To run:

./curseofwar-sdl [usual args]

Don't try to install. It does not work correctly.

I have the following problem: Do we need to call the SDL executable "curseofwar-sdl" or "curseofwar"?

On one hand, I would like to name two executables differently, so you will be able to make and install both. On the other hand, what should we do with the manpage, changelog, and probably other things that are called "curseofwar" already? Do we install them as is for both versions? Do you have any experience with issues like this. It looks like the Doungeon Crawl Stone Soup Makefile builds executable "crawl", no matter what version you want to build.

[Sicness]

Hi.
I got an error:
output-sdl.h:26:17: fatal error: SDL.h: No such file or directory

Looks like you forgot to add SDL.h

About name of bin: My opinion is curseofwar-sdl. Because:

1. ncurses version is a base :)
2. May there will be a qt, opengl and another versions :)

[a-nikolaev]

Do you know, is it ok to install manpage "curseofwar.6.gz" etc, but "curseofwar-x" executable?

[Sicness]

AFAIK, no. Each bin must have a manpage.

We can set $(EXEC) in Makefile in dependency on ncurses/sql. By this way, we can save rest of all install steps untouched.
I mean for example:
-sed "s/%VERSION%/$(VERSION)/g" $(EXEC).6 | gzip -c > $(MANDIR)/$(EXEC).6.gz
Will install needed manpage :)

But, we have to have special manpage for surceofwar-sdl OR do one more sed to set by sed %EXEC%. Last is better.

WDYT?

[a-nikolaev]

I have ho idea ) Maybe you are right, it sounds ok to me. Does Debian has any instructions for this kind of problem?

[Sicness]

Yeap, I think do one more sed is good idea until manpages will be different. AFAIK, Debian doen't have spesial instructions on that, but i'm sure there is "best practics" :) And I'll know it when I'll try to publish a multi package.
Anyway, it's not a problem for us.
Will you change Makefile by yourself?

[a-nikolaev]

Ok. Yeah, don't do pull requests for now. There will be other changes in the makefile, and in the source code. For example, images must be installed correctly, so pull requests will only complicate things. I will also look at other game projects to see what their developers do.

[a-nikolaev]

Hey guys, I ended up with the following installation principle:

1. We build differently named executables curseofwar and curseofwar-sdl.
2. All game data: images (and campaigns and maps in future) are installed to $(DESTDIR)/$(PREFIX)/share/curseofwar. So this data will be shared between two execs.
3. curseofwar.6 manpage and the changelog.gz are installed in any case, no matter what executable you actually install.
4. curseofwar-sdl.6 is a stub manpage that mostly refer to the main manpage and is installed only together with the SDL executable.

My implementation is rather sloppy at the moment:

To build a game for running it in the same directory without installation: make or make SDL=yes. In this case the SDL version loads images from the local directory ./images.

To build for installation:

make DESTDIR=/absolute/path {SDL=y}

To install this executable and other files

make DESTDIR=/absolute/path {SDL=y} install

To uninstall:

make DESTDIR=/absolute/path {SDL=y} uninstall

It's possible to build, install and uninstall both versions, doing something like this:

make DESTDIR=/home/me/game 
make DESTDIR=/home/me/game SDL=y

make DESTDIR=/home/me/game install
make DESTDIR=/home/me/game SDL=y install
...
make DESTDIR=/home/me/game uninstall
make DESTDIR=/home/me/game SDL=y uninstall

I don't like my implementation myself, but it kinda does the job, at least it demonstrates the idea, how everything can be installed.

[a-nikolaev]

There is a major flaw in the current version. If you make and install to a temporary DESTDIR, wich is a common practice when making a package from sources (say with Arch AUR, and probably everywhere else), the executable will be searching for images there. Even if the package is later installed to /, for exmaple.

I don't know what I was thinkng about. It's relly stupid, sorry.

[Sicness]

We all are learning on our own mistakes ) It's ok and somethins funny if not fatal :D
About DESTDIR - yes, I forgot that too. For example, debian packaging system runs Makefile with DESTDIR=pwd/debian/$PACKAGE/, and on installing put files into root.

We can see here why developing and testing in branch in good :)

[Sicness]

Request our testing when it will be needed.

[a-nikolaev]

New attempt:

DESTDIR specifies where you install executables, manpages, changelog.

DATADIR = where the executable will be looking for the game data files, e.g. images

INSTALL_DATA=yes to copy/remove images (and any other game data) to the DATADIR folder at make install/uninstall.

If INSTALL_DATA is not defined, it is the responsibility of the package to copy the data..

So, something like this should work, for example:

make SDL=y DESTDIR=/ DATADIR=/home/user/.curseofwar/ 
make SDL=y DESTDIR=/ DATADIR=/home/user/.curseofwar/ DATA_INSTALL=y install  
make SDL=y DESTDIR=/ DATADIR=/home/user/.curseofwar/ DATA_INSTALL=y uninstall

By Linux standards DATADIR should be /usr/share/curseofwar/ actually. In future, I hope to make the game automatically search in the standard directories like ~/.curseofwar/ or ~/.config/curseofwar/, trying to follow XDG http:https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

[Sicness]

Alexey, What about "If you make and install to a temporary DESTDIR, wich is a common practice when making a package from sources"
When deb package will have been compiling, I'll have to set temporary DATADIR in ~/debian/curseofwar/usr/share/curseofwar . Of course, when the package will be installed, data files will be in /usr/share/curseofwar.
I think it will be an issue for packaging.

[a-nikolaev]

I think, it's better to make DATADIR optional, and rely primarily on standard paths, such as $HOME/.config/game, $HOME/.game, /usr/local/share/game, .. Of course, taking into account all env. variables like $XDG_CONFIG_DIRS.

It simplifies installation, and its convenient: any user can simply copy all new data in one of those directories, and it will work. Then, DATADIR variable becomes really optional, and only needed if you wish to install data with make, or if you want to keep this data in a non-standard place. It will promote player's involvement for making their own tilesets, maps, etc.

[Sicness]

Agree with your last meassage.
Are you sure $HOME/.config/game can be used for data (not configs) files?

[a-nikolaev]

Anton you will do this:

make DATADIR=/usr/share/curseofwar
make DESTDIR=~/debian/curseofwar install
cp -r images ~/debian/curseofwar/usr/share/curseofwar/

Yeah, copy by hand. Do you see what I mean?

[a-nikolaev]

I agree though that these manipulations with DATADIR and DESTDIR are still ugly.. We should go for search in standard directories.. I will implement this sarch first. Maybe tomorrow, or on Saturday.

[Sicness]

Yes, I understand. We can do something like that in the package.
But we should to be autosearching data on game executing. I think you agree with that too :)

[a-nikolaev]

Yep, I think DATADIR should simply add one more directory to the list.

I think, there will be a function like findfile("maps/subdir/b.dat") that is looking in all directories known to the executable. And the XDG standard I referred previously says pretty clearly what is the order of priority for the standard directories.

There must be some compatibility layer for Windows in this findfile function that changes slashes to backslashes, but that's it.

[Sicness]

1. I think we can do search just once (on game execution). And exit if not found. I think there will no cases when half of data in one dir and rest of data in other dirs :)
2. AFAIK (maybe I'm wrong), Windows functions can work fine with slashes and backslashes.
3. We can add "one more directory to the list", but we don't have to. We can search in working dir and common paths. Anyway, we can do and that :)
4. Let's add a command line arg for set datadir.

[a-nikolaev]

(1) Well, the point for searching every time is to have some data in /usr/share/..., and also to let players put new files somewhere in their home directory.

Because we don't load a lot of files, and it is done only when starting the game, it should not take much computational resources, but will be rather convenient.

(3) exactly, you can, but don't have to. (4) yes.