On Wed, Mar 03, 2021 at 03:48:38PM +0000, Stuart Henderson wrote: > On 2021/03/03 07:27, Greg Steuck wrote: > > On Wed, Mar 3, 2021 at 12:32 AM Stuart Henderson <[email protected]> > > wrote: > > > > > > Validated to be reasonable by building devel/sqlports. I take the > > > > success of sqlport rebuild as evidence that no dependency edges are > > > > left hanging. > > > > > > I don't think sqlports cares that a port is unhooked when calculating > > > dependencies, if the directory exists it can enter it. > > > > > > > So if anything still retained references my query would've shown a hit? > > Say you have > > ports/cat/port1 > ports/cat/port2 > > ports/Makefile has port1 > > port1 depends on port2 > > sqlports will generate records for FULLPKGNAME=cat/port1 including the dep > on cat/port2, but it won't generate records for FULLPKGNAME=cat/port2. > > If you want to be more sure then you can do a sqlports build with the ports > actually removed rather than unhooked, then a forgotten dep will cause it > to error out as make recurses into a nonexistent dir; but...
Err, nope actually, after the first walk over the ports tree, mksqlports will go over every dependency it found that's not already indexed. So it will generate records for cat/port1 and cat/port2
