On Saturday 21 April 2001  3:59 pm, Hubert Feyrer wrote:
> On Sat, 21 Apr 2001, Chris Gilbert wrote:
> > OPTIONAL_DEPENDS +=	pilot-link>=0.9.3:../../misc/pilot-link:message about
> > what this extra package will add.
>
> What will the second component here be used for?

So that we could actually lazy and just drop it onto the DEPENDS line easily, 
so we don't have to check versions, seems daft to replicate the same 
functionality that is provided elsewhere.

Also some people may want to have every option available turned on by 
default, there are people that like all the bells and whistles, and crashing 
bits :)

> If the optional pkg in
> question is already installed, it's not used, and if it's not installed,
> we sure don't want it installed, so I think we can just drop it, and
> display the message ("You could gain this functionality if you installed
> the FOO pkg: ...").
>
> Adding the found optional depends to the list of depends is fine, and I
> don't think it'll make bulk builds more complicated - they just won't have
> the optional depends installed, and thus aim for core functionality.

That's my thought, by having this functionality someone asks why isn't 
functionality X available, we can at least say it is if you compile it 
yourself, with package Y installed it will enable that ability.

Although we may want to be able to go the other way in bulk builds and make 
the optional_depends into depends, however this would give the flexibilty to 
pick either way.

It may depend what becomes optional, eg USE_GIF could be replaced with 
OPTIONAL_DEPENDS, IE if it's installed you've already made the choice that 
you want to use GIF's, and that you're willing to libel to any patent issues.

> > If an optional package needs to set options to enable the functionality
> > some way of detecting this might be needed eg:
> > .if ${OPT_pilot-link}
> > 	CONFIGURE_ENV+=  -enable-palm-link
> > .endif
>
> This is where it's getting messy.. where is OPT_pilot-link set?
> to be useful, it must be set before that line, and I can only guess the
> work is done by bsd.pkg.mk.

Indeed, this is why I mailed the list, I'm not quite sure exactly how this 
kind of thing could be added.  Maybe a pkg.optional.mk file which you 
include before the .if xxx parts, and it parses the OPTIONAL_DEPENDS into 
variables, and tag them onto the DEPENDS list.  Would this been seen as 
overcomplicating things?  Ideally I'd like to avoid adding too much 
complexity with this functionality.

My thinking now is that the file would be:
OPTIONAL_DEPENDS +=	pilot-link>=0.9.3:../../misc/pilot-link:message

.include <pkg.optional.mk>
.if ${OPT_pilot-link}
	CONFIGURE_ENV+=  -enable-palm-link
.endif

pkg.optional.mk does something like:
include bsd.prefs.mk
if optional packages are not to be used
	skip the rest of the pkg.optional.mk file
if optional packages are to always be used
	add them to the depends list and create the variables.
else
	if optional pkg exists
		add it to depends list
		create OPT_pkg_name variable.
	else
		output the message. (optionally perhaps?)


Chris