5686877cd4
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 commit87ac6383bb. 2) too-cold commit53fd7dd1ed. 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>
30 lines
424 B
Makefile
30 lines
424 B
Makefile
AM_CPPFLAGS = \
|
|
-include $(top_builddir)/config.h \
|
|
-I$(top_srcdir)/include \
|
|
-DLOCALEDIR=\"$(localedir)\"
|
|
|
|
AM_LDFLAGS = ../proc/libprocps.la -ldl
|
|
|
|
if WITH_NCURSES
|
|
usrbin_exec_PROGRAMS = \
|
|
top
|
|
|
|
top_SOURCES = \
|
|
top.h \
|
|
top.c \
|
|
top_nls.h \
|
|
top_nls.c \
|
|
$(top_srcdir)/lib/fileutils.c
|
|
|
|
dist_man_MANS = \
|
|
top.1
|
|
|
|
top_LDADD = @NCURSES_LIBS@
|
|
endif
|
|
|
|
EXTRA_DIST =
|
|
|
|
procpsngdir = $(docdir)
|
|
dist_procpsng_DATA = \
|
|
README.top
|