Re: [GIT PULL 00/29] perf/core improvements and fixes

[Ingo Molnar]

* Ingo Molnar <mingo@xxxxxxxxxx> wrote:

> Now it displays the spammy auto-detection all the time:
> 
> comet:~/tip/tools/perf> make
>   BUILD:   Doing 'make -j12' parallel build
> 
> Auto-detecting system features:
> ...                     backtrace: [ on  ]
> ...                         dwarf: [ on  ]
> ...                fortify-source: [ on  ]
> ...                         glibc: [ on  ]
> ...                          gtk2: [ on  ]
> ...                  gtk2-infobar: [ on  ]
> ...                      libaudit: [ on  ]
> ...                        libbfd: [ on  ]
> ...                        libelf: [ on  ]
> ...             libelf-getphdrnum: [ on  ]
> ...                   libelf-mmap: [ on  ]
> ...                       libnuma: [ on  ]
> ...                       libperl: [ on  ]
> ...                     libpython: [ on  ]
> ...             libpython-version: [ on  ]
> ...                      libslang: [ on  ]
> ...                     libunwind: [ on  ]
> ...                       on-exit: [ on  ]
> ...                stackprotector: [ on  ]
> ...            stackprotector-all: [ on  ]
> 
> maybe a new testcase fails on my box, but is not properly displayed?

Hm, a 'make clean' cleaned up the condition and it now works as expected. 

So what happened is that GCC got upgraded from 4.8.1 to 4.8.2 and 
test-all.c failed to build:

  comet:~/tip/tools/perf/config/feature-checks> make -i
  make: *** No rule to make target `/usr/lib/gcc/x86_64-redhat-linux/4.8.1/include/limits.h', needed by `test-all'.  Stop.

but the individual testcases got built successfully and the perf build was 
fine and correct - it's just that the test-all.c .d file never got updated 
due to the broken dependency.

I think Namhyung warned about this during the feature-detection 
discussion, and I dismissed the concern - but Namhyung was right, it's a 
real problem.

I think to fix this we should automatically clean out potentially stale .d 
files automatically after testcase build failures (be it test-all.c or any 
other testcase)?

That would still preserve all the good roles of these dependencies and it 
would preserve the build speed and detection of system library changes.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/