I have a question about ways to handle packages which have many different
options.  The package which caused me to think about this is scilab.  The
problem is this.

Scilab needs a Fortran compiler to build.  Therefore I can have something
like
.if !exists(/usr/bin/f77)
BUILD_DEPENDS+=	f2c-*:../../lang/f2c
.endif

This creates the following problem.  One of the features of scilab (which
some people probably never use and others probably use a lot) is that you
can write a fortran (or C) code routine, and from within scilab, have the
function built and dynamically loaded.  However, all the compiler
information that scilab uses is done at compile time.  Hence, if I build a
binary package on a machine with egcs so that /usr/bin/f77 exists, I can't
use the dynamic linking feature on a machine without /usr/bin/f77 even if
I have f2c!  I hate to force everyone who wants this package to have
f2c installed.

Also, scilab can use PVM.  Scilab can certainly be built on a machine
without the pvm package, just give --without-pvm as a configure option.
But, some people may want this option.  If scilab is built pvm, it can run
on a machine without pvm installed, you just cant make useof the pvm
features.  So once again, should everyone be forced via 
DEPENDS+=	pvm*:../../parallel/pvm3
to have the pvm package if the want scilab even if they don't care about
ever using the pvm features?

There's also some sort of TCL/TK interface too.  The same question
applies.  I've never used this feature and don't want to have to install
tcl and tk on my machine, but someone may want it.

Anyway, I sure this isn't the only package with different features which
can be turned on and off and there doesn't seem to be a good way of
dealing with this in our current package framework.

Thoughts?  Comments?

-Dan