Date: Tue, 22 Jun 2004 13:15:09 +0200 From: Oliver Eikemeier <eikemeier@fillmore-labs.com> To: Kris Kennaway <kris@obsecurity.org> Cc: ports@freebsd.org Subject: Re: incremental ports/INDEX builder Message-ID: <40D814BD.6030603@fillmore-labs.com> In-Reply-To: <20040622123418.GA15696@xor.obsecurity.org> References: <20040622083214.GA91013@sanatana.dharma> <20040622100327.GA12999@xor.obsecurity.org> <40D7F5EF.4090406@fillmore-labs.com> <20040622112326.GA14566@xor.obsecurity.org> <40D7FD85.2070201@fillmore-labs.com> <20040622114734.GA14959@xor.obsecurity.org> <40D809C3.6090402@fillmore-labs.com> <20040622123418.GA15696@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Kris Kennaway wrote: > On Tue, Jun 22, 2004 at 12:28:19PM +0200, Oliver Eikemeier wrote: > >>Some ports include a Makefile.local that isn't there. Of course >>they won't make it into CVS, but you can have them in local port >>trees. I just asserted that examples can be constructed where the >>make(1) approach fails, too. > > That's OK, I'm not trying to solve the halting problem here, only deal > with the dependencies in the CVS ports collection. My point was that > an implementation that only works for less than 100% of the changes > that are actually made to the ports collection (excluding the > pathological cases that don't and aren't going to occur) isn't a > solution I can use. That amounts to tracking .included files and > updating that dependency list when it changes, since those are the > corner cases that a straightforward implementation doesn't catch. I hope that my implementation is correct in the changes I've seen so far. I'm interested on integrating it in a build cluster that does check which packages may be directly affected and generates a blame log (done in this script, packges affected indirectly, e.g. via build dependencies should be done in a second step), does INDEx builds, version checks and alike and delivers the output to a queue on the package building cluster. The generated dependency file could also be used for portlint, to automatically check affected ports along with the port currently checked. I guess it could be advantageous where we able to break INDEX generation down to a modular process with defined interfaces. Just my 2 cents -Oliver
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40D814BD.6030603>