Hi,
You can cause a recursion in kbuild/make with the following:
make O=$PWD kernel/time.o
make mrproper
Of course no one would use O=$PWD (that's just the testcase),
but this happened too often:
/ws/linux/linux-2.6.23$ make O=/ws/linux/linux-2.6.23 kernel/time.o
(Oops - should have been O=/ws/linux/obj-2.6.23!)
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?
thanks,
Jan
* 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.
____
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.
Sam
On Sat, Sep 22, 2007 at 01:24:32PM +0200, Jan Engelhardt wrote:
> Hi,
>
>
> You can cause a recursion in kbuild/make with the following:
>
> make O=$PWD kernel/time.o
> make mrproper
>
> Of course no one would use O=$PWD (that's just the testcase),
> but this happened too often:
>
> /ws/linux/linux-2.6.23$ make O=/ws/linux/linux-2.6.23 kernel/time.o
> (Oops - should have been O=/ws/linux/obj-2.6.23!)
>
> 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?
Does the following patch fix it at your end?
Seems to work for me.
Sam
diff --git a/Makefile b/Makefile
index 6708e41..f787b05 100644
--- a/Makefile
+++ b/Makefile
@@ -115,7 +115,9 @@ saved-output := $(KBUILD_OUTPUT)
KBUILD_OUTPUT := $(shell cd $(KBUILD_OUTPUT) && /bin/pwd)
$(if $(KBUILD_OUTPUT),, \
$(error output directory "$(saved-output)" does not exist))
-
+# Check the OUTPUT directory is not the same as where we have kernel src
+$(if $(filter-out $(KBUILD_OUTPUT),$(shell /bin/pwd)),, \
+ $(error Output directory (O=...) specify kernel src dir))
PHONY += $(MAKECMDGOALS)
$(filter-out _all,$(MAKECMDGOALS)) _all:
Jan Engelhardt <[email protected]> wrote:
> You can cause a recursion in kbuild/make with the following:
>
> make O=$PWD kernel/time.o
> make mrproper
>
> Of course no one would use O=$PWD (that's just the testcase),
> but this happened too often:
>
> /ws/linux/linux-2.6.23$ make O=/ws/linux/linux-2.6.23 kernel/time.o
> (Oops - should have been O=/ws/linux/obj-2.6.23!)
>
> 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?
You can test for the existence of MAINTAINERS in the build dir and abort
if it's there.
--
My computer isn't that nervous...it's just a bit ANSI.
Fri?, Spammer: [email protected] [email protected]
[email protected] [email protected]
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.
____
> > 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.
Better would be to fix the bugs where we today clobber the sources.
Care to point out the exact cases you see.
Sam
On Sep 22 2007 22:52, Sam Ravnborg wrote:
>
>Does the following patch fix it at your end?
>Seems to work for me.
Yes.
>-
>+# Check the OUTPUT directory is not the same as where we have kernel src
>+$(if $(filter-out $(KBUILD_OUTPUT),$(shell /bin/pwd)),, \
>+ $(error Output directory (O=...) specify kernel src dir))
Should be "specifies".
> PHONY += $(MAKECMDGOALS)
>
> $(filter-out _all,$(MAKECMDGOALS)) _all:
>
On Sun, Sep 23, 2007 at 08:03:35AM +0200, Sam Ravnborg wrote:
> > > 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.
> Better would be to fix the bugs where we today clobber the sources.
> Care to point out the exact cases you see.
It is not about particular case, it is about whole environment.
* interactive:
shell (profile setup).--> source editing / patching
`-> building parts / doing tests
where profile is one particular source tree with particular
config/development goals. On multiple terminals (sessions), one
may just type in favorite shell `wana profile-xx` and environment
is set up there. I.e.
+ where ever you are, it's easy to go to current obj or src tree,
+ quilt knows its setup
+ kbuild does also
+ tracking files, sent to editor (e.g. emacsclient / emacsserver)
o easily composing file / change sets to be operated by quilt
o kbuild knows exactly what to check and possibly to rebuild
+ all actions are written to history, that can be imported into any session
o saving sessions
o restore sessions: checking profile consistency / updating
+ less ugly (e.g. just stupid bash command line) user interface
o even ordinary command line can be improved much-much more in
terms of efficiency and comfort
o more nice-looking information of what is happening and how is
happening
* automatic:
running setup of selected profiles:
o patch/update sources
o configure and (cross) build multiple source trees with multiple output
trees each.
o run time testing: emulators, hardware.
Many ideas, collected in kbuild-2.5-history.tar.bz2 back in 2000, are
still interesting and useful.
More i do development, more i realize, that i spend too much time to
do trivial and repeating things. And this time will not go less, if
something like that will be by hand.
I'd really like to see a work flow of best development staff, because
behind patches i can not see anything. And frankly, i doubt there's
anything significant there. The only sharing of tools i can see is
patch scripts (now quilt), diff-tools, linux/scripts. Still just tools.
There's no environment, where people would know particular configs for
editors, mailers, 2-3 steps easy to get right help messages, i.e
*environment*. UI tricks, like common, most useful, sh aliases for using
tools, different color schemas: for error/log output, editing C or asm
(with linux specific annotations, rules), tools like checkpatch, but not
checkpatch -- helper for developers to get changes checked and ready to
create actual patch, etc. etc. etc....
For example, i'd really like to have, candy C + diff color fontlocking
(emacs' brain damaged lexicon) for easy patch reviewing. I did some
trivial enhancements more than 3 years ago, like highlighting of actions
that change variable's value, thus, i don't do many stupid things in C any
more. I'd like to have candy fontlocking for sed and shell and
sed-in-shell syntax, etc. etc.
And all this is needed just for stupid terminal emulator. So, what
people are doing all this time? Noo, X? There's no X, period.
____