On Mon, Feb 16, 2009 at 03:01:10AM +0100, ERSEK Laszlo wrote: > Paul Wise wrote: > > > And now onto the package review: > > > > Why does your diff.gz patch the Makefile? Shouldn't you add those > > changes to the upstream Makefile? > > I don't think so. As my general, hobbyist free software development > policy, I *always* and *exclusively* follow the Single Unix Specification:
Actually, that's great. I wish there could be more people like you.
Really, I do.
[snip]
> One such thing would be the set of paths I'd to put under an "install:"
> rule. This has clearly no place in Makefile.dev which is my personal
> playground, or Makefile.portable, which is what it is called. (The
> default Makefile, using gcc, is a concession towards the fact that most
> people have gcc without an appropriate c89 wrapper.)
>
> I simply couldn't satisfy all conceivable users with any "install:"
> target. I believe there's a world out there that doesn't conform to the
> FHS, for example users with install rights only in their respective
> (freely structured) home directories. Maybe someone doesn't want to
> install the manual at all. I just list the files one should consider
> installing, in the README.
Sorry for replying to a month-old e-mail :)
A possible solution - the one I use for all my pieces of software -
is to use environment variables. Since most of the things that vary
between OS's and installations are either paths or user/group names or
permission modes, they can, indeed, be configured with variables.
NB: I am well aware that all of the following depends on make(1)
understanding the ?= syntax. If the programs should be packaged for
OS's which do not have a ?=-aware version of make(1), that could,
indeed, be a problem. There are those who would just wave this problem
away with "oh well, you can always use GNU make, right?"; I'm not
one of them, and if you really intend your software to be ported to
non-?=-aware-make-OS's, then all of the following should be taken with
a grain of salt - or just look at the end for another possible solution :)
The way I do it is to set several variables so that the default behavior
is close to my FreeBSD system and then just pass them on the "make"
command-line when building the Debian, RedHat, or what-have-you package:
LOCALBASE?= /usr/local
PREFIX?= ${LOCALBASE}
BINDIR?= ${PREFIX}/bin
LIBDIR?= ${PREFIX}/lib
MANDIR?= ${PREFIX}/man/man
MAN1DIR?= ${MANDIR}1
BINOWN?= root
BINGRP?= wheel
BINMODE?= 555
SHAREOWN?= ${BINOWN}
SHAREGRP?= ${BINGRP}
SHAREMODE?= 444
...and a couple more. Then, for Debian, I just need to change PREFIX,
MANDIR, and BINGRP, and it all works just fine (the modes do not need
changing, there's dh_fixperms for that ;)
Of course, those could be redone for a FHS/Linux system instead:
LOCALBASE?= /usr
MANDIR?= ${PREFIX}/share/man/man
BINGRP?= root
BINMODE?= 755
SHAREMODE?= 644
...and then the other ports, e.g. to FreeBSD, would have to pass those
variables either on the make(1) command line or in the environment.
Either way, it's a possible solution.
As to the ?=-aware make(1) problem, a possible solution for that one
would be a shell script which generates the Makefile with values from
the shell script's environment. This is getting dangerously close
to a "configure" script and not all that far away from the autotools,
but, no, I am not trying to convince you to use those - I don't, myself :)
But sometimes, a shell "configure" script is enough to Do The Right Thing(tm).
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@space.bg r...@freebsd.org
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
Thit sentence is not self-referential because "thit" is not a word.
pgpiEkJmgXZum.pgp
Description: PGP signature
