pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pkgsrc scanning performance benchmarks



On 12/2/2016 09:14, 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.
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.


I'm seeing some obvious technical problems with that exact proposal so maybe lets reduce this to "come up with a light way to get this information systematically". It would require infrastructure updates.
John



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



Home | Main Index | Thread Index | Old Index