[ On Mon, June 22, 1998 at 03:10:07 (-0700), Alistair Crooks wrote: ]
> Subject: Re: making pkgsrc patch sets (was: pkg/5617: Apache-1.3.0 package OS configuration not quite right) 
>
> tech-ports has nothing to do with this discussion. This should be on
> tech-userlevel.

oops.  I knew that.  duped out again by the old /usr/ports confusion!

> > > The other one quickly replaces ifdef __FreeBSD__ with both freebsd and netbsd
> > > defs. It is meant to be run on patches.
> 
> Please don't do this - the correct way is to test the BSD definition in
> <sys/param.h>, and then:
> 
> #if (defined(BSD) && BSD >= 199306)
> ...
> #endif

I think lots of people avoid this form because they're never sure what
number to put there.  I know I've got to think twice before I use a
number.  I'm usually sure when all BSD's, even the old ones, have a
feature unique to themselves, but there doesn't seem to be a canonical
list of what features can be wrapped with what numbers.

Realistically speaking any feature specific #ifdef should use a name
unique to to that feature, and if you don't have autoconf then you might
write a conf.h that uses the numbers, assuming you know what numbers are
right to use.

> > (Often another *perfect* use for "#ifdef unix"!!!!!! [unless it's a
> > 4.4BSD specific feature].)
> 
> Can we at least start to use __unix__, please? I do not want to have to
> try to explain to imake, for example, to try to compile unix.c, rather
> than 1.c. imake is borken, you say? Right. But too much depends on it to
> change its behaviour. And, just for the record, I loathe imake with a
> vengeance.

Absolutely.  I only favour "#ifdef unix" for existing code and
tradition.  New code, or code undergoing true maintenance, should avoid
it or fix it to use either a feature-unique word or "__unix__", which is
definitely within the domain of implementation specific constants.

> > Strictly speaking I disagree quite strongly with the suggestion of
> > breaking patches up into one "change" per file.  This is a suitable
> > approach only for providing elective fixes.  When providing a change set
> > that's self consistent and entirely mandatory then it is much safer to
> > generate and use it as one single patch file.
> 
> Ahhh, sigh, and I'm usually one of the supporters of the "everything's a
> file" philosophy too.

Who/what exactly offered the one-change-per-patch-file suggestion for
pkgsrc modules?  Is there any justification for it that I've not yet
encountered?  If not is there any reason why we cannot simply eliminate
that suggestion and slowly revert to using just one patch file?

-- 
							Greg A. Woods

+1 416 443-1734      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>