It seems that most of what needs to be done is change all of the
#include <xpm.h> to #include <X11/xpm.h> (in nearly every
source) and comment out #include <values.h> in ball.c
Packaging is going to be the hard part; I don't fully understand
it's make system (imake). Someone else will have to do that. :p
BTW, it runs WAYYY too fast to be playable by default; didn't look
into a way to limit framerate.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
(That would be Image::Xpm, so my guess is that isn't what you want)
$ fink info system-pkgconfig-xpm
Scanning package description files..........
Information about 8865 packages read in 1 seconds.
system-pkgconfig-xpm-3.5.11-1: [virtual pkgconfig package representing xpm]
X Pixmap Library
.
This package represents the pkgconfig file found at:
/usr/X11R6/lib/pkgconfig/xpm.pc
.
It expects the following pkgconfig packages to exist:
x11 x11
.
Web site: http://www.finkproject.org/faq/usage-general.php#virtpackage
.
Maintainer: Fink Core Group fink-core@lists.sourceforge.net
If xboing uses xpm.pc, then a BuildDepends: system-pkgconfig-xpm would be handy. If not, then dependencies on x11* would be appropriate. We don't have a separate xpm package, unlike some Linux distros. You can probably go with BuildDepends: x11-dev, fink (>=0.32); Depends: x11-shlibs; RuntimeDepends: x11.
Last edit: Alexander Hansen 2013-11-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm throwing in the towel on this; i should have payed some attention to the fact that the required build tools went out of style when autotools came along. Even if somebody who spoke autotools solved that problem, a game that was unplayably fast on a 2003 computer is not likely to be any better on today's machines.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=713731
It seems that most of what needs to be done is change all of the
#include <xpm.h> to #include <X11/xpm.h> (in nearly every
source) and comment out #include <values.h> in ball.c
Packaging is going to be the hard part; I don't fully understand
it's make system (imake). Someone else will have to do that. :p
BTW, it runs WAYYY too fast to be playable by default; didn't look
into a way to limit framerate.
I started to take a look at this. I have two questions:
1) Is the dependency for xpm properly satisfied by "image-xpm-pm" or "system-pkgconfig-xpm"?
2) The copyright doesn't exactly match any of the ones we have for the LICENSE field. I've attached the copyright file.
From "fink info":
$ fink info image-xpm-pm
Scanning package description files..........
Information about 8865 packages read in 8 seconds.
image-xpm-pm-1.12-1: Manipulate xpm image files
.
Web site: http://search.cpan.org/dist/Image-Xpm
.
Maintainer: None fink-devel@lists.sourceforge.net
(That would be Image::Xpm, so my guess is that isn't what you want)
$ fink info system-pkgconfig-xpm
Scanning package description files..........
Information about 8865 packages read in 1 seconds.
system-pkgconfig-xpm-3.5.11-1: [virtual pkgconfig package representing xpm]
X Pixmap Library
.
This package represents the pkgconfig file found at:
/usr/X11R6/lib/pkgconfig/xpm.pc
.
It expects the following pkgconfig packages to exist:
x11 x11
.
Web site: http://www.finkproject.org/faq/usage-general.php#virtpackage
.
Maintainer: Fink Core Group fink-core@lists.sourceforge.net
If xboing uses xpm.pc, then a BuildDepends: system-pkgconfig-xpm would be handy. If not, then dependencies on x11* would be appropriate. We don't have a separate xpm package, unlike some Linux distros. You can probably go with BuildDepends: x11-dev, fink (>=0.32); Depends: x11-shlibs; RuntimeDepends: x11.
Last edit: Alexander Hansen 2013-11-30
The license looks like a BSD-style license to me.
I'm throwing in the towel on this; i should have payed some attention to the fact that the required build tools went out of style when autotools came along. Even if somebody who spoke autotools solved that problem, a game that was unplayably fast on a 2003 computer is not likely to be any better on today's machines.