On Fri, Dec 02, 2016 at 09:14:25AM -0600, John Marino wrote:
On 12/2/2016 09:06, Joerg Sonnenberger wrote:
On Fri, Dec 02, 2016 at 09:00:54AM -0600, John Marino wrote:
On 12/2/2016 08:54, Joerg Sonnenberger wrote:
On Fri, Dec 02, 2016 at 08:41:33AM -0600, John Marino wrote:
as an aside, I'm highly suspicious when I see PKG_INFO invoked just with a
scan. I have a feeling most uses can be challenged, but I haven't even
begun the scratch the surface on any of this.
As I said, e.g. for gtk2, the x11 option affects the downwards
depedendency tree. The pkg_info call tries to extract the current
option, it doesn't distingiush between bulk build and manual invocation.
That's basically my point. I think that's a logic flaw.
For PKG_INFO to work against a dependency, the assumption is that dependency
is already installed. The makefile should be designed with the baseline
that nothing is installed.
If it is not already installed, it extracts the current setting. That's
a good chunk of the "make" invocations seen.
so it spawns PKG_INFO regardless of success, point 1.
It is optimised for the normal (interactive) use where it can't know in
advance whether the dependency exists or not.
point 2, it seems to me one could augment the infrastructure to optionally
load the OPTION settings of any package, .e.g.
VIEW_OPTIONS= <cat1>/<port1> <cat2>/<port2>
so that the options settings would be available and just use regular make
logic and avoid both invocations. This kind of infrastructure would clean
up the makefiles (through standardization) and significantly reduce
spawning.
See note about caching builtin.mk results. This is essentially the same
thing. The logic for requestions build options is:
pkgbase := gtk2
.include "../../mk/pkg-build-options.mk"
It won't become simpler.