build-sys: eliminate dependencies for the NUMA support
authorJim Warner <james.warner@comcast.net>
Thu, 25 Apr 2013 05:00:00 +0000 (00:00 -0500)
committerCraig Small <csmall@enc.com.au>
Sat, 4 May 2013 23:12:07 +0000 (09:12 +1000)
commit5686877cd4c83a2daf1be6f2f7f93cd2c1451e75
tree16091aa0d31ca94e64765a50ebcfa754a7af4ed1
parenta076c37d07674203522a79d73cfb5f4fd894dd3a
build-sys: eliminate dependencies for the NUMA support

Oh that poor ol' build system. With this patch it will
have gone through three separate incarnations in terms
of NUMA/Node support. Those 3 iterations consisted of:

1. A 'porridge too hot' where the top numa support was
enabled if it was built in the presence of libnuma and
the numa.h header. But if the numa library wasn't part
of core packages, that would have broken poor old top.

2. A 'porridge too cold' where numa support was off by
default and must have been explicitly enabled when the
./configure script was run. This could have meant that
distros might not distribute a numa-aware procps, even
though their numa library would have been distributed.

3. And this 'porridge' where the top numa support will
become a 'plug-in' feature activated when the presence
of libnuma.so can be verified at runtime. We'll do our
own loading and symbol resolution (with some help from
dlopen in libdl). Thus maintainers' responsibility for
enabling numa support and then satisfying that library
dependency is now an entirely optional --disable-numa.

As Goldilocks might say about our current configure.ac
"Ummm, I think this porridge tastes just about right".

Reference(s):
. 1) too-hot
commit 87ac6383bb575d964ba9ef6a100b61cdcdc7f15d
. 2) too-cold
commit 53fd7dd1ed120f901cbb31e69453720b038a7ac6
. original idea from: Dr. Fink <werner@suse.de>
http://www.freelists.org/post/procps/top-NUMA-node-CPU-utilization-support,18

Signed-off-by: Jim Warner <james.warner@comcast.net>
configure.ac
top/Makefile.am