On Tue, Jun 22, 2010 at 08:42:23AM +0200, Robert Schwebel wrote: > On Mon, Jun 21, 2010 at 11:03:02PM +0200, Michael Olbrich wrote: > > On Mon, Jun 21, 2010 at 10:16:04PM +0200, Remy Bohmer wrote: > > > 2010/6/20 Michael Olbrich <[email protected]>: > > > > On Sat, Jun 19, 2010 at 03:54:06PM +0200, Remy Bohmer wrote: > > > >> 2010/6/19 Michael Olbrich <[email protected]>: > > > >> > Inspired by Remy Bohmer dependencies on installed files, I did > > > >> > the same for patches and series files. Adding more > > > >> > dependencies, especially to early build stages is always > > > >> > tricky. I'd like to avoid unnecessary rebuilds. So please have > > > >> > a look and tell me what you think. > > > > > > I just tested it, and I must say that it does not entirely fit to > > > our work-flow... What we typically do is edit in the kernel tree > > > and use ' quilt refresh' to update a patch, after which we do a > > > 'ptxdist drop kernel.compile' followed by ' ptxdist go'. It would > > > be annoying if after every ' quilt refresh' the entire kernel tree > > > is being rebuild from scratch because a patch is updated... > > > > I know. But if you want to tell someone else "update from svn/git/.. > > and "ptxdist go", then that's exactly what you want. I'm thinking > > about adding an option for "ptxdist setup" to disable such extra > > dependencies. > > Patches modify content of a packet, so dropping it's compile stage in > that case is the right thing to do. No need to recompile from scratch.
Wrong. If I change a patch, commit it to svn, and tell you to update, then you need start at the extract stage. We have two work patterns that would benefit from dependencies on patches. Unfortunately they require different dependencies. I'm not sure how to solve this. Any Ideas? Regards, Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | -- ptxdist mailing list [email protected]
