Re: [kbuild-devel] Some feedback on using kbuild

2002-06-25 Thread Peter Samuelson
[I wrote] > (cd $s; find * -type d) | xargs mkdir -p; > (cd $s; >exec find * \( -type d -exec mkdir \{} \; \) -o \ > \( -type f ! -name \*.prepend ! -name \*.append -print \) ) | > while read f; do This is redundant - the second mkdir is not needed. Should be: (cd $s; exec fi

Re: [kbuild-devel] Some feedback on using kbuild

2002-06-25 Thread Brendan J Simon
Sam Ravnborg wrote: >On Tue, Jun 25, 2002 at 11:34:09PM +1000, Keith Owens wrote: > >>One other point: kbuild must not assume that it is running on Linux. >>Users must be able to build the Linux kernel from _any_ evironment that >>supports Posix and has a _small_ set of GNU tools. This include

Re: [kbuild-devel] Some feedback on using kbuild

2002-06-25 Thread Peter Samuelson
[Sam Ravnborg] > > This does not stop any attemp to make a simple wrapper that > > creates and maintain a BUILD_TREE. > > To check timestamps and link accordinly should not take too much > > time, at least not at the second run. [Greg Banks] > Ok, why don't you and Peter Samuelson get together

Re: [kbuild-devel] Some feedback on using kbuild

2002-06-25 Thread Sam Ravnborg
On Wed, Jun 26, 2002 at 01:48:04AM +1000, Greg Banks wrote: > Ok, why don't you and Peter Samuelson get together, create such a thing and > we can compare it against kbuild2.5? If it's simple and a win, great! The same reasons as so many other I belive: I do not have the need, I do not have the t

[kbuild-devel] Re: Problem with configurators and customized help texts perarchitecture.

2002-06-25 Thread Steven Cole
On Tue, 2002-06-25 at 10:53, Robert Love wrote: > On Tue, 2002-06-25 at 12:44, Steven Cole wrote: > > > Now, I realize that this particular problem could be easily solved by > > simply rewording the help text for CONFIG_NR_CPUS so that one text would > > be appropriate and accurate for all archs.

[kbuild-devel] Problem with configurators and customized help texts perarchitecture.

2002-06-25 Thread Steven Cole
Greetings all, Since kernel 2.5.3, the monolithic Configure.help file has been broken up into a hundred or so Config.help files. This division potentially allows for customized help texts for different architectures. For example, the CONFIG_SMP help text is different in arch/i386/Config.help an

Re: [kbuild-devel] Some feedback on using kbuild

2002-06-25 Thread Greg Banks
Sam Ravnborg wrote: > > On Wed, Jun 26, 2002 at 12:36:11AM +1000, Greg Banks wrote: > > I think the problem of Makefile bits in shadow trees is really > > quite difficult. Keith's solution of pre-processing Makefiles and > > Makefile.appends from all the shadow trees into a combined Makefile > >

Re: [kbuild-devel] Some feedback on using kbuild

2002-06-25 Thread Greg Banks
Peter Samuelson wrote: > > > So now we assume BK? What's next, Python 2.1? > > Touché. No, my point was not that we can assume BK, but that we can > assume the developer is willing to install whatever tools he needs to > get the job done. > > I think the assumption is valid, assuming the deve

Re: [kbuild-devel] Some feedback on using kbuild

2002-06-25 Thread Sam Ravnborg
On Tue, Jun 25, 2002 at 11:34:09PM +1000, Keith Owens wrote: > > One other point: kbuild must not assume that it is running on Linux. > Users must be able to build the Linux kernel from _any_ evironment that > supports Posix and has a _small_ set of GNU tools. This includes > Solaris, Cygwin and

Re: [kbuild-devel] Some feedback on using kbuild

2002-06-25 Thread Sam Ravnborg
On Wed, Jun 26, 2002 at 12:36:11AM +1000, Greg Banks wrote: > I think the problem of Makefile bits in shadow trees is really > quite difficult. Keith's solution of pre-processing Makefiles and > Makefile.appends from all the shadow trees into a combined Makefile > doesn't handle all the cases but

Re: [kbuild-devel] Some feedback on using kbuild

2002-06-25 Thread Peter Samuelson
[Greg Banks] > I think the problem of Makefile bits in shadow trees is really quite > difficult. Keith's solution of pre-processing Makefiles and > Makefile.appends from all the shadow trees into a combined Makefile > doesn't handle all the cases but is the best attempt I've seen so > far. Agre

Re: [kbuild-devel] Some feedback on using kbuild

2002-06-25 Thread Greg Banks
Peter Samuelson wrote: > > [Sam Ravnborg] > > > Obviously the kernel build system should work for everyone irrespective > > > of the SCM system in use. This put at least the following demands: > > > 1) Separate OBJ and SRC tree > > > 2) That kbuild does not touch any files in the SRC

Re: [kbuild-devel] Some feedback on using kbuild

2002-06-25 Thread Peter Samuelson
[CCs trimmed] [Sam Ravnborg] > > Obviously the kernel build system should work for everyone irrespective > > of the SCM system in use. This put at least the following demands: > > 1) Separate OBJ and SRC tree > > 2) That kbuild does not touch any files in the SRC tree Agreed. It lo

Re: [kbuild-devel] Some feedback on using kbuild

2002-06-25 Thread Keith Owens
On Tue, 25 Jun 2002 23:06:39 +1000, Greg Banks <[EMAIL PROTECTED]> wrote: >I agree with Keith, shadow trees rock. I think they are probably the single >most useful feature of kbuild 2.5. I fervently hope we end up with shadow >trees or something like them by the end of Linux 2.5. Greg covered

Re: [kbuild-devel] Some feedback on using kbuild

2002-06-25 Thread Greg Banks
G'day, I'll just briefly unlurk on the subject of kbuild before getting back to the kconfig bughunt. Sam Ravnborg wrote: > > On Mon, Jun 24, 2002 at 08:49:34AM +1000, Keith Owens wrote: > > [...] > There is absolutely no requirement that all kernel developers uses > the same SCM system. Agreed