Re: [kbuild-devel] vmlinux.lds not marked for update when building on OS X and changing config options

2007-05-24 Thread Mike Frysinger
lovely ... looks like Darwin fails at life when it comes to respecting POSIX and open() with O_TRUNC and a 0 byte file ... in particular, this statement: http://www.opengroup.org/onlinepubs/009695399/functions/open.html If O_TRUNC is set and the file did previously exist, upon successful completi

Re: [kbuild-devel] vmlinux.lds not marked for update when building on OS X and changing config options

2007-05-24 Thread Mike Frysinger
On 5/21/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote: > Could you please check this. > > The line that says: > deps_arch/blackfin/kernel/vmlinux.lds := \ > list all the files that the .lds file is dependent on (the prerequisites). > For the config option BOOT_LOAD look for include/config/boot/lo

Re: [kbuild-devel] [rfe] easier customization of kconfig for non-Linux projects

2007-05-24 Thread Yann E. MORIN
Hello all! Sorry to jump into the discussion, but... On Thursday 24 May 2007 08:40, Sam Ravnborg wrote: > The intent with this is clear but the solution you suggest albeit simple > does not really match where we could end up with kconfig. > Recently Roman added support for options in the kconfig

Re: [kbuild-devel] [rfe] easier customization of kconfig for non-Linux projects

2007-05-24 Thread Sam Ravnborg
On Thu, May 24, 2007 at 09:23:40AM -0400, Mike Frysinger wrote: > On Thursday 24 May 2007, Sam Ravnborg wrote: > > The intent with this is clear but the solution you suggest albeit simple > > does not really match where we could end up with kconfig. > > Recently Roman added support for options in t

Re: [kbuild-devel] [rfe] easier customization of kconfig for non-Linux projects

2007-05-24 Thread Mike Frysinger
On Thursday 24 May 2007, Sam Ravnborg wrote: > The intent with this is clear but the solution you suggest albeit simple > does not really match where we could end up with kconfig. > Recently Roman added support for options in the kconfig language > and I would assume we could deal with most of this