[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070922222311.GQ24301@flower.upol.cz>
Date: Sun, 23 Sep 2007 00:23:11 +0200
From: Oleg Verych <olecom@...wer.upol.cz>
To: Sam Ravnborg <sam@...nborg.org>
Cc: Jan Engelhardt <jengelh@...putergmbh.de>, zippel@...ux-m68k.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Unfortunate infinite make recursion
On Sat, Sep 22, 2007 at 10:40:02PM +0200, Sam Ravnborg wrote:
> On Sat, Sep 22, 2007 at 05:42:52PM +0200, Oleg Verych wrote:
> > * Sat, 22 Sep 2007 13:24:32 +0200 (CEST)
> > []
> > > The make O=$PWD truncates the Makefile, making it necessary to run `git
> > > checkout Makefile` - should you have git; or reextract the tarball
> > > (should you /still/ have it). Well, can we catch this case somehow?
> >
> > Read-only source-tree for kbuild user, end of question. By current kbuild
> > one can garbage source by various means. Read-write for quilt, git and
> > editor users.
>
> Please Oleg.
> You know very well that most people will not have their kernel src RO.
Sure, if it will be not comfortable.
But if kbuild deals with this transparently, it must be OK. Brokenness
due to binutils, kbuild, root user bugs won't garbage source. Only thing
to ask from experienced users *and* kernel developers, is
`useradd kbuild`, everything else will not bother anybody.
I just express my vision, of course. But see, i can't play with kernel
sources error-free now. If i type some `make` somewhere in obj or src
tree, i need to know, that vanilla source stays so in any circumstances.
Currently it's not.
It is about making things in order on my working place (not looking to be
in order, though :). Not thinking every time, if something fscked sources,
saves my and time of diff/patch. Experimenting/testing/finding fixes with
small amount of in-development sources in obj tree, also very helpful.
____
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists