Re: RFA: fix in features/Makefile

[Daniel Jacobowitz <drow@false.org>]

On Sun, Aug 24, 2008 at 06:02:40PM -0600, Tom Tromey wrote:
> Yeah, I should have looked first.
> 
> I disabled stdout buffering and used frysk's ftrace to get a stack
> trace at the point where the weird stuff is written:
> 
> #0 0x00110416 in __kernel_vsyscall() from [vdso]
> #1 0x05e4d135 in new_do_write() from libc-2.7.so
> #2 0x05e4d41f in _IO_do_write@@GLIBC_2.1() from libc-2.7.so
> #3 0x05e4dd28 in _IO_file_overflow@@GLIBC_2.1() from libc-2.7.so
> #4 0x05e50793 in __overflow() from libc-2.7.so
> #5 0x05e4a55b in putc() from libc-2.7.so
> #6 0x082f35c5 in _rl_output_character_function() from gdb
> #7 0x006c554a in tputs() from libtinfo.so.5.6
> #8 0x082f3741 in _rl_enable_meta_key() from gdb
> #9 0x082df0d8 in readline_initialize_everything() from gdb
> #10 0x082def5c in rl_initialize() from gdb
> #11 0x081a6081 in tui_initialize_readline() from gdb
> #12 0x081a6ab7 in tui_init() from gdb

stdout isn't a tty... dubious we should be doing this if it is.  I'm
not sure why you get tui here, though, I don't think I do.  Do you
have the gdbtui binary installed as gdb?

> Tom> This patch also makes it so that the .c files are always rebuilt in
> Tom> response to a 'make'.  Without the FORCE code, make was not running
> Tom> the rule for me.
> 
> Daniel> If you're going to change the generating code, IMO it's reasonable to
> Daniel> remove and remake the generated files by hand...
> 
> Note that due to the use of move-if-change, you only get updates if
> there really were any.  This change just makes it simpler to ask for
> the changes.  I don't really care either way though.

Makes sense, this makefile is already for manual use only and it's not
like they take a long time.

-- 
Daniel Jacobowitz
CodeSourcery