[ On Friday, April 19, 2002 at 12:37:55 (-0500), Frederick Bruckman wrote: ]
> Subject: Re: how can we create PATCHFILES that are not DISTFILES?
>
> No. First of all, everytime we've had conditional patches in the past,
> it's lead to major maintenance headaches, not the least of which is
> that there's no way the author can accept *the* patch. (Which patch?)

In this case the author has nothing to do with it -- it's a patch that
must be made to a distributed file in order to correctly set a default
behaviour of the package.  The author supplied default is only correct
for one choice -- there's at least one or two other extremely common
choices.  I.e. this is strictly a pkgsrc issue -- nothing the author can
to do help, now or ever.

> What andrew was trying to say, is that the current policy is to have
> *one* patch, and switch on and off desired behavior via compile time
> flags.

This isn't a compiled file -- there's no post processing done during
build and none that would make sense.  It really has to be a build-time
modification too.  A "patch" really is the ideal mechanism for making
the requisite change(s).  I.e. "patch" is the compiler in this case and
I think it is far more suitable for the job than 'sed', or 'm4'.  The
proposed mechanism is undoutably more widely usable in this form in
other packages than other tools could ever be too.

I could do this:

	post-patch:
		${PATCH} ${PATCH_DIST_ARGS} < ${FILESDIR}/${SELECTED_PATCH}

but that prevents all the other nice patch-handling stuff from working,
and/or means re-inventing mechanisms that already exist in almost the
ideal form in bsd.pkg.mk.  The tiny tweak I suggested solves the
problem, but as I discussed Mark's suggestion can be integrated in with
all the existing patch handling mechanisms in pkgsrc much better than
what I initially proposed.

I'm certain there are other situations where this same technique is the
best way to solve the problem too.  'sed' gets very tricky when the
context of a change is necessary to identify the correct pattern to
replace with a new value, and it's much harder to maintain a complex
'sed' expression than it is to maintain a group of patch files.

(In this particular case I could 'sed' the patch to make the option
selection, instead of having multiple optional patch files, but that's
also not a very elegant solution and still doesn't really fit in with
the existing patch handling mechanisms.)

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>