Peter Valchev writes:
> Suddenly on Sat, Jan 27, 2001 at 05:34:53PM -0700, J Shoemaker wrote:
> : Restored default flags as the default and placed the optimizations
> : in a FLAVOR since nothing else seemed to make sense.
> :
> : Done; also added a DEINSTALL message since there will be data files
> : created and left behind by the program that shouldn't be removed
> : automaticly.
>
> Well, here is my personal opinion:
>
> - I really don't think that the explanation of the directory structure
> of the game should be in the DESCR file - create a pkg/MESSAGE files for
> these things ( /var/crafty note, etc.)
>
Well, I can see where you're coming from, but I would have to
disagree. I'm trying to make this something that can be used system
wide by any user which is not what is assumed by the author. There's
no need to maintain seperate personal versions of books; in fact, it's
better not to, this way crafty will learn from all the games it plays
regardless of who is playing against it and this information will be
availalble to all users. Any user can do pkg_info crafty-18.1, but
pkg/MESSAGE is only shown when it is installed. I think it's better
to leave the info where those familiar with crafty can find it when
they notice that it's not following what they consider 'normal
procdedure.'
> - Usually you may want to set NEED_VERSION in your Makefile
Yes, I'll have to add that.
> - In your case I think it would be way easier to use
> {pre,do,post}-target,
> instead of modifying the game's Makefile so much (in this case,
> specifically do-install ?) - seems to be a better way.
>
It probably would be, but my personal preference is to modify the
makefile. I had planned to send in a patch to the author so that this
wouldn't be necessary for later releases. As far as I can see, this
is just a cosmetic difference and will work regardless.
> - There is no documentation, why don't you grab the faq and readme from
> the ftp (as adding them as DISTFILES), and install them - would be
> useful. (read.me; crafty.doc; crafty.faq) - again, you would probably
> want to use 'do-install' or 'post-install' depending on the way you
> decide to do the things.
>
Well, most people who will use this program already basicly know the
contents of these files 'by heart,' so there's little point in forcing
everyone to fetch them. Those that don't will find out by using
pkg_info. I usually favor a minimalist approach, but if the
committers decided that we should have those files by default, then of
course it'll be done that way.
> - i386 and sparc are not the only architectures OpenBSD runs on, as you
> seem to assume adding only their entries in the Makefile. If you don't
> want to set up a specific entry for every one, create one 'openbsd' that
> seems to contain the standart stuff. Like:
>
> .if ${MACHINE_ARCH} == "i386"
> ALL_TARGET= openbsd-i386
> .elif ${MACHINE_ARCH} == "sparc"
> ALL_TARGET= openbsd-sparc
> .else
> ALL_TARGET= openbsd # where is stuff supposed to work
> .endif # everywhere OpenBSD runs
> # - add an entry for it too, then
>
I didn't assume that at all. I simply am not familiar enough with
those architectures to start adding anything other than defaults,
which aren't even provided for other than i386 and sparc. The
addition of a generic target is a good idea though, thanks; I'll add
that.
>
> "Do NOT start with an uppercase letter unless semantically significant,
> So you can fix that _minor_ thing which teases the eye to look better.
>
minor eye-candy suggestion understood and fixed. :)
> Hope that helps!
>
It does indeed, thanks.
// J Shoemaker
Attachment:
gzlM8XzlME3L.gz
Description: GNU Zip compressed data