Re: [kbuild-devel] kbuild status

2002-10-07 Thread Greg KH
On Mon, Oct 07, 2002 at 07:30:18PM -0500, Peter Samuelson wrote: > > I hear ya. Remember the 2.1.1xx days? Linus looked at the relatively > mature "uusb" project and basically said "Wow, what a load of crap, the > usb spec isn't *nearly* this complex." Then he spent a weekend hacking > up an e

Re: [kbuild-devel] kbuild status

2002-10-07 Thread Peter Samuelson
[Brendan J Simon] > Thanks for that information. Looks like Kai's work will/may > eventually do what I want but when will it be mainstream, that is the > question. If by "mainstream" you mean "in 2.4", probably never. There is just no motivation to backport it, and I doubt Marcelo would accept

[kbuild-devel] howto determine error?

2002-10-07 Thread Randy.Dunlap
Hi, I'm getting the following error message. How can I determine where the actual problem is? Will Greg's gcml2 syntax checker find this? (I'll find out tomorrow.) Preparing scripts: functions, parsing.scripts/Menuconfig: ./MCmenu73: line 71: syntax erro

[kbuild-devel] Re: RfC: Don't cd into subdirs during kbuild

2002-10-07 Thread Kai Germaschewski
On Thu, 3 Oct 2002, Sam Ravnborg wrote: > On Thu, Oct 03, 2002 at 10:01:20PM +0200, Sam Ravnborg wrote: > > Now it's testing time.. [...] You must be missing some of the changes (My first push to bkbits was incomplete, since I did inadvertently edit Makefile without checking it out, I do that

[kbuild-devel] Re: RfC: Don't cd into subdirs during kbuild

2002-10-07 Thread Kai Germaschewski
On Thu, 3 Oct 2002, Sam Ravnborg wrote: > > -obj-$(CONFIG_ACPI_INTERPRETER) := $(patsubst %.c,%.o,$(wildcard *.c)) > > +obj-y := dsfield.o dsmthdat.o dsopcode.o dswexec.o dswscope.o \ > > +dsmethod.o dsobject.o dsutils.o dswload.o dswstate.o > > Should that have been: > obj-$(CONFI

[kbuild-devel] Re: RfC: Don't cd into subdirs during kbuild

2002-10-07 Thread Xavier Bestel
Le jeu 03/10/2002 à 04:59, Kai Germaschewski a écrit : > > Hi, > > I'd appreciate to get comments on the appended patch. It's mostly cleanups > and the like, but the interesting part is the last cset, which is actually > fairly small: > > 14 files changed, 64 insertions(+), 47 deletions(-) >

[kbuild-devel] Re: RfC: Don't cd into subdirs during kbuild

2002-10-07 Thread Xavier Bestel
Le jeu 03/10/2002 à 16:56, Kai Germaschewski a écrit : > > This would avoid recursive make, which isn't really a good idea (even if > > it's used widely). Here is a good agument about that: > > http://www.cse.iitb.ac.in/~soumen/teach/cs699a1999/make.html > > I think I heard that before, but I wo

[kbuild-devel] Re: RfC: Don't cd into subdirs during kbuild

2002-10-07 Thread Kai Germaschewski
On 3 Oct 2002, Xavier Bestel wrote: > Could you do instead: > > include subdir/Makefile > ? It's not quite that easy, unfortunately ;( > This would avoid recursive make, which isn't really a good idea (even if > it's used widely). Here is a good agument about that: > http://www.cse.iitb.

Re: [kbuild-devel] RfC: Don't cd into subdirs during kbuild

2002-10-07 Thread Kai Germaschewski
On Thu, 3 Oct 2002, Peter Samuelson wrote: > Which top dir, src or obj? Most end users will expect obj topdir. > More on that below. Yes, I think obj topdir is the way to go - and you're right, it can be made work mostly with vpath and does not need much more. > > So gcc/ld/.. are now called

Re: [kbuild-devel] kbuild status

2002-10-07 Thread Brendan J Simon
Peter Samuelson wrote: >Well, there's http://www.??.kernel.org/pub/linux/kernel/v2.5/ChangLog-*, >search for "kai@". He seems to have started in 2.5.7. > >Off the top of my head, the main kbuild2.5 features 2.5.40 *doesn't* >have would be: > >* separate source and object trees - but see below >

Re: [kbuild-devel] kbuild status

2002-10-07 Thread Peter Samuelson
[Brendan J Simon] > Is there a site that documents the changes the Kai has made or is > making ? Well, there's http://www.??.kernel.org/pub/linux/kernel/v2.5/ChangLog-*, search for "kai@". He seems to have started in 2.5.7. Off the top of my head, the main kbuild2.5 features 2.5.40 *doesn't* h