Re: State of the new config & build system

Andreas Bombe
2002-01-04T02:00:17Z

On Fri, Jan 04, 2002 at 08:50:52AM +1100, Keith Owens wrote:
> On Thu, 3 Jan 2002 16:30:55 -0500 (EST),
> Alexander Viro <viro@math.psu.edu> wrote:
> ><shrug> kernel build doesn't have to use it - if I mount a writable layer
> >atop of the clean tree and build in the resulting tree, build system
> >doesn't need to have any idea of that fact.
>
> I have one big problem with unionfs and make, it cannot handle this
> scenario.
>
> * Mount COW layer over clean tree.
> * Edit a file, writing to the COW layer.
> * Build the kernel.
> * Decide that you don't want the change, delete the COW version,
> exposing the original version of the file, timestamp goes backwards.
> * Build the kernel.
> * make sees source timestamp < object timestamp and does not rebuild,
> the kernel source and object do not match.

Isn't that a thinko in there? The build using the edited file would
happen in the same layer as that file or in another one on top. If it's
the same, the build would be deleted with the change.

If it's in another one on top you'd be removing a layer in the middle.
I don't know if that should be possible without user intervention
(unmount build and change layers, delete change layer, mount build layer
over source). There is something said about Unix and ropes, I remember.
Then again I don't know the unionfs idea in these details, so I may be
wrong.

Unionfs as I understand it would be great for editing/patching and
building. Build a kernel in the pristine sources, mount a COW layer
over it where you patch/edit, build there. In the ideal case the COW
layer would only build the changed file(s) and link vmlinux with all the
other objects from the pristine build. This wouldn't affect the
pristine build itself at all, no make problems there when you remove the
COW build&change layer.

--
Andreas Bombe <bombe@informatik.tu-muenchen.de> DSA key 0x04880A44