Re: pkgsrc performance

[Joachim König <him%online.de@localhost>]

Quentin Garnier wrote:
> It's an orthogonal issue.  The problem here is bl3.mk files including
> other bl3.mk files.  What you describe is essentially changing a
> recursive algorithm into an iterative one;  that doesn't solve the issue
> here which is to know what information can be discarded when discovering
> dependencies.
I did not want to change the algorithm to an iterative one, the only
thing I wanted to achieve was the decoupling of dependency declaration
and the actual inclusion based on the following observation:

It's only necessary to actually include a buildlink3.mk at most twice:

- if it's a direct dependency include it at "level 0"
- if it's an indirect dependency include it at a "level > 0"

if the buildlink3.mk file is included when the dependency is declared (the
include is the implicit declaration) then there is no way to avoid multiple
inclusion.

By declaring the dependency without including it immediately and later on
including it conditionally based on knowledge if it has already been 
included
at "level 0" or "level > 0" we have the chance to avoid unnecessary 
inclusion.

If the dependency via buildlink3.mk should be declared in DEPENDS or
in a separate variable is othogonal though.

> That said, your approach is interesting;  it would centralize the code
> where it is decided whether or not to go on with the discovery, instead
> of using .if !defined() blocks.  But it would still require changing all
> bl3.mk files, so the amount of work is at least equivalent.
What I propose could be done by a simple mechanical transformation of 
all the
'.include "../../<category>/<pkgname>/buildlink3.mk"' to a variable 
assignment like
"BUILDLINK3_DEPENDS += <category>/<pkgname>" and some additions
to the dependency infrastructure to recursively include the 
buildlink3.mk files
conditionally.