On Tuesday 30 December 2003 01:12 pm, Daniel Eggert wrote:
> > On Monday 29 December 2003 06:10 pm, grant beattie wrote:
> > > On Mon, Dec 29, 2003 at 06:08:21PM -0500, Adam C. Migus wrote:
>
> <snip>
>
> > So then why do the variables _need_ to be per-package?  I actually
> > like being able to say USE_{SOMETHING} and know it means "if a
> > package has support for {SOMETHING} I want to compile it in..."
>
> One good example: I have mail/postfix, security/sasl and
> databases/openldap. I need to compile postfix with sasl and openldap
> support and I need sasl with openldap support. This doesn't work if
> openldap is compiled with sasl support as it will create a circular
> dependency and everything wil break once I try to 'make update'.
>

The fact that using USE_SASL creates a circular dependency when doing 
make update in this situation is a problem with the logic in update.  
Solving it by not defining USE_SASL is like trying to avoid breaking 
your leg by not walking.

> > How difficult would it be to offer the decision making logic behind
> > some kind of construct to allow simple inclusion or exclusion lists
> > in mk.conf?
>
> Well, a simple thing would be to use _USE_ variables (such as
> POSTFIX_USE_SASL) instead of general USE_ (e.g. USE_SASL), but this
> would of course create a vast amount of _USE_ variables.
>
> /Daniel

This is precisely my point.  I'm trying to avoid a 100 line mk.conf file 
consisting predominantly of {SOMETHING}_USE_{SOMETHINGELSE} in favor of 
something like USE_{SOMETHING}_FOR={LIST OF THINGS}.  The idea being 
it's more consice, less confusing to look at, more scalable, etc.

Even if no one wants this type of directive there should be nothing 
wrong with declaring USE_{SOMETHING} for universal usage of it therefor 
I think you've found a run-time bug in `make update' rather than a 
problem with global variables.

Adam