On Tuesday, December 30, 2003 8:06 PM, Adam C. Migus typed:


> 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.


Well, both yes and no: Circular dependencies break "make update" because
they "have to". Circular dependencies are bad per-se -- with and without
"make update".

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

I disagree. A package (e.g. SASL) might allow other packages to be built
with additional functionality. But one doesn't necessarily want this
functionality in _all_ packages

/Daniel