[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkgsrc performance
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
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
By declaring the dependency without including it immediately and later on
including it conditionally based on knowledge if it has already been
at "level 0" or "level > 0" we have the chance to avoid unnecessary
If the dependency via buildlink3.mk should be declared in DEPENDS or
in a separate variable is othogonal though.
What I propose could be done by a simple mechanical transformation of
'.include "../../<category>/<pkgname>/buildlink3.mk"' to a variable
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.
"BUILDLINK3_DEPENDS += <category>/<pkgname>" and some additions
to the dependency infrastructure to recursively include the
Main Index |
Thread Index |