On Fri, 19 Apr 2002, Greg A. Woods wrote:

> [ On Friday, April 19, 2002 at 12:12:44 (-0400), Andrew Brown wrote: ]
> > Subject: Re: how can we create PATCHFILES that are not DISTFILES?
> >
> > >I've been trying to update a pkgsrc module and I've run into a situation
> > >where the best way to enable an option seems to be to optionally patch
> > >the source before building, using a specific patch selected from a set
> > >of multiple optional patches (included in say ${FILESDIR}), based on
> > >some setting in mk/bsd.prefs.mk and/or /etc/mk.conf.
> >
> > make your patch contain all features, and then enable each feature
> > based on the presence of some preprocessor token.  ie, if you have a
> > patch that does something for alpha machines, your patch would contain
> > code surrounded by #ifdef alpha/#endif.
>
> What are you talking about?
>
> There's no invocation of cpp in the data path between the patch file and
> the patch program.  Are you proposing one?

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?)

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.

Now, recalling that you said that your solution didn't lend itself
easily to (any reasonably available) compile time flags, I suggested
you invent some. You can switch them on by adding CPPFLAGS+= to the
top-level, pkgsrc "Makefile". (Granted, I didn't make that clear.)

With that, you can manhandle CPPFLAGS at the pkgsrc level, using the
many hooks that are available to the pkgsrc' Makefile but not, by
default, to the package's "Makefile". E.g.:

.if "../../mk/bsd.prefs.mk"

.if ${OPSYS} == "NetBSD" && ${USE_INET6} == "YES"
CPPFLAGS+= NETBSD_INET6=1
.endif

.if ${OPSYS} == "SunOS" && ${USE_SOCKS} == "YES"
CPPFLAGS+= SUN_SOCKS_HACK=1
.endif

.if "../../mk/bsd.pkg.mk"

This permits /etc/mk.conf settings to have an effect in a way that's
visible to the pkgsrc maintainer (at least), and sophisticated user.
(Activating pkgsrc settings within the package's Makefile would just
be horrible. In the past, it's lead to a real mess with "perl".)

An additional advantage to that, over Andrew's initial suggestion, is
that it doesn't depend on the vagaries of compilers -- in the patched
source, you switch on only what you want to switch on.

Regards,

Frederick