procps/top/Makefile.am

30 lines
424 B
Makefile
Raw Normal View History

AM_CPPFLAGS = \
-include $(top_builddir)/config.h \
-I$(top_srcdir)/include \
-DLOCALEDIR=\"$(localedir)\"
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>
2013-04-25 10:30:00 +05:30
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