Subject: Re: Extreme lethargy when dependencies are missing (part 2)
To: <>
From: None <mcmahill@mtl.mit.edu>
List: tech-pkg
Date: 10/10/2001 20:52:12
On Wed, 10 Oct 2001, Frederick Bruckman wrote:

> On Wed, 10 Oct 2001 mcmahill@mtl.mit.edu wrote:
> 
> > But how was it that glib was already installed?  Sorry for all the
> > questions, but I'm still missing something.
> 
> No, it's OK. If it's not clear to you, there are certainly others that
> have no idea what I'm talking about either, which is why I'm taking
> the liberty of responding back to the list...

i think i deleted the wrong to: line anyway ;)

> To build the ${DEPENDSFILE} while under "gnome", you first do
> something like
> 
>   make -V DEPENDS | xargs -n1 echo > ${WRKDIR}/${DEPENDS.tmp}
> 
> Now you run the file repeatedly. This almost works,
> 
>   awk -v FS=: '{ print $2 }' ${DEPENDS.tmp} | \
>   xargs -n1 sh -c 'cd $0; make -V DEPENDS | xargs -n1 echo' \
>   >> ${DEPENDS.tmp2} && mv ${DEPENDS.tmp2} ${DEPENDS.tmp}
> 
> except it doesn't expand the variables in the DEPENDS.

make show-var VARNAME=DEPENDS 

will expand variables though.

> Now you can
> trim duplicates, resolve variables, whatever, but don't sort! Finally,
> you reverse the file into ${DEPENDSFILE}. [Mere details ommitted.]
> 
> Now you're all done with the indefinite recursion hassle. For whatever
> top-level target you're doing (fetch, install, package), you simply
> run the list, cd'ing to each directory, in turn, and executing it's
> non-recursing little brother (e.g. checksum, no-recurse-check-install,
> no-recurse-package).
> 
> One other immediate advantage is that "make fetch-list" becomes simply
> "make -n fetch", and no bogus installing of packages when you only
> want to fetch distfiles. You could do "make fetch" in one window, give
> it a little head start, and then "make package" in another.

ok.  So what happens is you still get recursion and duplication because if
several of your DEPENDS share a common DEPENDS, then you duplicate some
work there.  However, since you do it once, you win because only the top
level package does it and you can simply do non-recursive targets in each
of the (now flattened) DEPENDS.  I think I finally understand!

> Most of this would be transparent, but one thing: the implied
> dependencies must no longer be recorded in ${PKGDBDIR}, as doing so
> for each package would defeat the whole purpose of the scheme. We have
> other reasons to make this change (the perl-mk fiasco), so it's still
> overall a good thing.

yep.

-Dan