mirrors/procps
0
0
Fork 0
mirror of https://gitlab.com/procps-ng/procps.git synced 2024-11-23 18:14:15 +08:00
Code Issues Packages Projects Releases Wiki Activity
e914f4b068
procps/Makefile.am

408 lines
7.8 KiB
Makefile
Raw Normal View History

build-sys: tweak make & activate some overlooked tests This commit is just preparing for adding an Itemtables verification test by reorganizing stuff and activating a few previously inactive (overlooked?) test programs. Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-15 23:10:10 +08:00
Added Cygwin build support strverscmp is included to satisfy a dependency in Cygwin. Excluded utmp and prctl functions that are not supported currently.
2016-03-11 07:04:27 +08:00
CYGWINFLAGS =
if CYGWIN
Port of merge request 49 to newlib Wayne Porter made !49 which added Cygwin support to the master branch This is the port of those changes to newlib
2017-08-19 21:05:22 +08:00
CYGWINFLAGS += -lintl
usrbin_exec_PROGRAMS =
Added Cygwin build support strverscmp is included to satisfy a dependency in Cygwin. Excluded utmp and prctl functions that are not supported currently.
2016-03-11 07:04:27 +08:00
endif
build-sys: correct all Makefile.am files for LOCALEDIR, etc Some of the latest changes to Makefile.am files are missing. This patch restores the LOCALEDIR variable, among others, and dispenses with the include directives in the ps/ and top/ subdirectories since they're no longer needed.
2012-01-02 23:08:58 +08:00
AM_CPPFLAGS = \
-include $(top_builddir)/config.h \
build-sys: add $(top_srcdir) to include search dir This is required for out-of-tree build to work, since many source files include e.g. proc/*.h which is not under the include/ directory. Tested that `make distcheck` starts working after this patch. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 08:09:39 +08:00
-I$(top_srcdir) \
build-sys: correct all Makefile.am files for LOCALEDIR, etc Some of the latest changes to Makefile.am files are missing. This patch restores the LOCALEDIR variable, among others, and dispenses with the include directives in the ps/ and top/ subdirectories since they're no longer needed.
2012-01-02 23:08:58 +08:00
-I$(top_srcdir)/include \
build-sys: suppress '-Wunused-result' with AM_CPPFLAGS Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-07-14 13:00:00 +08:00
-Wno-unused-result \
build-sys: Enable optional hardening flags With the configure option --enable-harden-flags the CFLAGS and LDFLAGS are manipulated to provide some hardening protection to the binaries. psmisc uses these flags on by default with no troubles, however it doesn't have a library in it either. References: https://wiki.debian.org/Hardening
2016-04-25 15:07:22 +08:00
-DLOCALEDIR=\"$(localedir)\" \
@HARDEN_CFLAGS@
AM_LDFLAGS = @HARDEN_LDFLAGS@
build-sys: take autotools in use again This will revert change at Oct 2002 when autotools support was removed. Unlike before the package developers are expected to use ./autogen.sh to generate ./configure script, and run make after that. The build system is also able to create, with make dist, a tar ball release which compiles correctly, and has files which seemed to be important to have. The patch removes few unnecessary files, but no everything. Files procps.lsm and procps.spec in git repository are useless as is, but I left them lying around for someone who can make more justified call about removal of them. Last, but not least package version number is set 3.3.0 to distinct this procps from the sourceforge's upstream procps. Please notice that libproc relese is kept as 3.2.8. Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2011-06-04 22:26:58 +08:00
build-sys: merge automake subdirs into toplevel This will be required for subdir-objects, otherwise automake will have problems with more than one Makefile.am having rules to build the same files. Tested that it builds and both `make check` and `make distcheck` work. Tested `make install` and compared the tree with the one installed before this commit, both installed the binaries to the same locations. The binaries are also in the same location in the build tree (for instance, ps/pscommand is still there.) Checked the binaries for the correct libraries linked into them. Binary sizes matched before and after this change. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:28:53 +08:00
PACKAGE_VERSION = @PACKAGE_VERSION@
build-sys: take autotools in use again This will revert change at Oct 2002 when autotools support was removed. Unlike before the package developers are expected to use ./autogen.sh to generate ./configure script, and run make after that. The build system is also able to create, with make dist, a tar ball release which compiles correctly, and has files which seemed to be important to have. The patch removes few unnecessary files, but no everything. Files procps.lsm and procps.spec in git repository are useless as is, but I left them lying around for someone who can make more justified call about removal of them. Last, but not least package version number is set 3.3.0 to distinct this procps from the sourceforge's upstream procps. Please notice that libproc relese is kept as 3.2.8. Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2011-06-04 22:26:58 +08:00
ACLOCAL_AMFLAGS = -I m4
build-sys: add NLS support Add GNU gettext internationalization and localization support. Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2011-10-09 03:14:21 +08:00
SUBDIRS = \
build-sys: add missing files to distribution Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2011-10-19 16:37:03 +08:00
include \
Manpage translations in Makefiles The translated manpage generation has moved from scripts to Makefiles. This asists with conditional building as well, no need to regenerate the German pgrep man page if both the original pgrep.1 and man-po/de.po is not changed. My Makefile-fu fails me on producing a cross-product or double iteration for languages and man pages. Until that is solved each man page is explicitly built. No big deal but it doesn't look elegant in the Makefile. Languages will be picked up automatically if they are found in man-po, man-po/top or man-po/ps The README describes the three-step process for translating the files, incase I forget or someone else wants to update them.
2014-06-28 21:38:13 +08:00
man-po \
build-sys: add NLS support Add GNU gettext internationalization and localization support. Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2011-10-09 03:14:21 +08:00
po \
build-sys: merge automake subdirs into toplevel This will be required for subdir-objects, otherwise automake will have problems with more than one Makefile.am having rules to build the same files. Tested that it builds and both `make check` and `make distcheck` work. Tested `make install` and compared the tree with the one installed before this commit, both installed the binaries to the same locations. The binaries are also in the same location in the build tree (for instance, ps/pscommand is still there.) Checked the binaries for the correct libraries linked into them. Binary sizes matched before and after this change. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:28:53 +08:00
testsuite
build-sys: take autotools in use again This will revert change at Oct 2002 when autotools support was removed. Unlike before the package developers are expected to use ./autogen.sh to generate ./configure script, and run make after that. The build system is also able to create, with make dist, a tar ball release which compiles correctly, and has files which seemed to be important to have. The patch removes few unnecessary files, but no everything. Files procps.lsm and procps.spec in git repository are useless as is, but I left them lying around for someone who can make more justified call about removal of them. Last, but not least package version number is set 3.3.0 to distinct this procps from the sourceforge's upstream procps. Please notice that libproc relese is kept as 3.2.8. Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2011-06-04 22:26:58 +08:00
AM_CFLAGS = -Iproc
library: Rename to libproc-2 What to call the new library? Keep using libprocps wouldn't do, its a very different library from the programs' point of view. It would also mean we could have some clashes around the packages (two package names, same library name). The ancient procps used libproc or libproc-a.b.c where a.b.c was the package version. Kept the revision numbers down (it was always 0.0.0) but the name of the library changed. So if we use libproc-2 is there a clash with an ancient procps? procps v 2.0.0 was around in 1999 so it was 22 years ago, also the name of the library would have been libproc-2.0.0.so not libproc-2.so so we're fine with that. libproc-2 seems to fit, our second major re-work of the procps library. Signed-off-by: Craig Small <csmall@dropbear.xyz>
2021-02-20 19:30:31 +08:00
LDADD = ./proc/libproc-2.la $(CYGWINFLAGS)
build-sys: take autotools in use again This will revert change at Oct 2002 when autotools support was removed. Unlike before the package developers are expected to use ./autogen.sh to generate ./configure script, and run make after that. The build system is also able to create, with make dist, a tar ball release which compiles correctly, and has files which seemed to be important to have. The patch removes few unnecessary files, but no everything. Files procps.lsm and procps.spec in git repository are useless as is, but I left them lying around for someone who can make more justified call about removal of them. Last, but not least package version number is set 3.3.0 to distinct this procps from the sourceforge's upstream procps. Please notice that libproc relese is kept as 3.2.8. Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2011-06-04 22:26:58 +08:00
Port of merge request 49 to newlib Wayne Porter made !49 which added Cygwin support to the master branch This is the port of those changes to newlib
2017-08-19 21:05:22 +08:00
if CYGWIN
library: Rename to libproc-2 What to call the new library? Keep using libprocps wouldn't do, its a very different library from the programs' point of view. It would also mean we could have some clashes around the packages (two package names, same library name). The ancient procps used libproc or libproc-a.b.c where a.b.c was the package version. Kept the revision numbers down (it was always 0.0.0) but the name of the library changed. So if we use libproc-2 is there a clash with an ancient procps? procps v 2.0.0 was around in 1999 so it was 22 years ago, also the name of the library would have been libproc-2.0.0.so not libproc-2.so so we're fine with that. libproc-2 seems to fit, our second major re-work of the procps library. Signed-off-by: Craig Small <csmall@dropbear.xyz>
2021-02-20 19:30:31 +08:00
AM_LDFLAGS += ./proc/libproc-2.la $(CYGWINFLAGS)
Port of merge request 49 to newlib Wayne Porter made !49 which added Cygwin support to the master branch This is the port of those changes to newlib
2017-08-19 21:05:22 +08:00
endif
transform =
if !CYGWIN
transform += s/pscommand/ps/; $(program_transform_name)
sbin_PROGRAMS = \
sysctl
else
transform += s/pscommand/procps/; $(program_transform_name)
endif
build-sys: merge automake subdirs into toplevel This will be required for subdir-objects, otherwise automake will have problems with more than one Makefile.am having rules to build the same files. Tested that it builds and both `make check` and `make distcheck` work. Tested `make install` and compared the tree with the one installed before this commit, both installed the binaries to the same locations. The binaries are also in the same location in the build tree (for instance, ps/pscommand is still there.) Checked the binaries for the correct libraries linked into them. Binary sizes matched before and after this change. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:28:53 +08:00
Port of merge request 49 to newlib Wayne Porter made !49 which added Cygwin support to the master branch This is the port of those changes to newlib
2017-08-19 21:05:22 +08:00
if !CYGWIN
build-sys: merge automake subdirs into toplevel This will be required for subdir-objects, otherwise automake will have problems with more than one Makefile.am having rules to build the same files. Tested that it builds and both `make check` and `make distcheck` work. Tested `make install` and compared the tree with the one installed before this commit, both installed the binaries to the same locations. The binaries are also in the same location in the build tree (for instance, ps/pscommand is still there.) Checked the binaries for the correct libraries linked into them. Binary sizes matched before and after this change. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:28:53 +08:00
bin_PROGRAMS = \
build-sys: install binaries in bindir (get rid of usrbin_execdir) The "usrbin_execdir" hack meant to install some binaries in /bin and others in /usr/bin. However: - It is very inflexible: not much control on the final directory name and it is not possible to get rid of the usr/bin suffix without patching the build system. - It is hard to use: it requires configure to receive --exec_prefix=/ and other settings do not make much sense. It is not very obvious that that setting needs to be passed and it takes a while to figure it out. - It produces garbage with the default setup: the default prefix of /usr/local ends up installing the binaries under /usr/local/usr/bin which does not make any sense. Furthermore, the requirement to split binaries in /bin and /usr/bin is not that strong since some distributions adopted the /usr merge and so would agree to just deploy all binaries to /usr/bin directly. Distributions that would still like to split /bin from /usr/bin should actually move binaries such as `ps` and `kill` to /bin after the install of procps-ng is complete. After all, they are the ones responsible for determining what are the binaries that need to be in the root partition and that list depends on their early boot init scripts, so it is possible that the list must be augmented with other binaries from this package. Therefore, I propose here to get rid of that hack and simply install all the binaries to bindir instead, which solves the problems described above and simplifies the build and install of procps-ng. Tested that it builds and both `make check` and `make distcheck` work. Tested that `make install` works and produces the expected tree, the only difference being the absence of the bogus /usr/local/usr/bin directory and now all binaries are merged into /usr/local/bin as expected. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 14:27:13 +08:00
ps/pscommand \
build-sys: take autotools in use again This will revert change at Oct 2002 when autotools support was removed. Unlike before the package developers are expected to use ./autogen.sh to generate ./configure script, and run make after that. The build system is also able to create, with make dist, a tar ball release which compiles correctly, and has files which seemed to be important to have. The patch removes few unnecessary files, but no everything. Files procps.lsm and procps.spec in git repository are useless as is, but I left them lying around for someone who can make more justified call about removal of them. Last, but not least package version number is set 3.3.0 to distinct this procps from the sourceforge's upstream procps. Please notice that libproc relese is kept as 3.2.8. Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2011-06-04 22:26:58 +08:00
free \
pgrep \
pkill \
pmap \
pwdx \
tload \
uptime \
configure: Add --disable-w Some systems implement utmp as a stub so it doesn't make sense to have a non-functioning w. This change mitigates #193 and !126 References: procps-ng/procps!129 procps-ng/procps!126 procps-ng/procps#193
2021-04-24 03:58:36 +08:00
vmstat
pidwait: Rename from pwait pwait is already in at least Debian in a different package References: https://bugs.debian.org/982391
2021-02-15 18:10:06 +08:00
if BUILD_PIDWAIT
bin_PROGRAMS += pidwait
pgrep: add pwait
2020-02-24 11:02:59 +08:00
endif
Port of merge request 49 to newlib Wayne Porter made !49 which added Cygwin support to the master branch This is the port of those changes to newlib
2017-08-19 21:05:22 +08:00
else
usrbin_exec_PROGRAMS += \
ps/pscommand \
free \
pgrep \
pkill \
pmap \
uptime \
configure: Add --disable-w Some systems implement utmp as a stub so it doesn't make sense to have a non-functioning w. This change mitigates #193 and !126 References: procps-ng/procps!129 procps-ng/procps!126 procps-ng/procps#193
2021-04-24 03:58:36 +08:00
vmstat
Port of merge request 49 to newlib Wayne Porter made !49 which added Cygwin support to the master branch This is the port of those changes to newlib
2017-08-19 21:05:22 +08:00
endif
build-sys: install binaries in bindir (get rid of usrbin_execdir) The "usrbin_execdir" hack meant to install some binaries in /bin and others in /usr/bin. However: - It is very inflexible: not much control on the final directory name and it is not possible to get rid of the usr/bin suffix without patching the build system. - It is hard to use: it requires configure to receive --exec_prefix=/ and other settings do not make much sense. It is not very obvious that that setting needs to be passed and it takes a while to figure it out. - It produces garbage with the default setup: the default prefix of /usr/local ends up installing the binaries under /usr/local/usr/bin which does not make any sense. Furthermore, the requirement to split binaries in /bin and /usr/bin is not that strong since some distributions adopted the /usr merge and so would agree to just deploy all binaries to /usr/bin directly. Distributions that would still like to split /bin from /usr/bin should actually move binaries such as `ps` and `kill` to /bin after the install of procps-ng is complete. After all, they are the ones responsible for determining what are the binaries that need to be in the root partition and that list depends on their early boot init scripts, so it is possible that the list must be augmented with other binaries from this package. Therefore, I propose here to get rid of that hack and simply install all the binaries to bindir instead, which solves the problems described above and simplifies the build and install of procps-ng. Tested that it builds and both `make check` and `make distcheck` work. Tested that `make install` works and produces the expected tree, the only difference being the absence of the bogus /usr/local/usr/bin directory and now all binaries are merged into /usr/local/bin as expected. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 14:27:13 +08:00
lib_LTLIBRARIES = \
library: Rename to libproc-2 What to call the new library? Keep using libprocps wouldn't do, its a very different library from the programs' point of view. It would also mean we could have some clashes around the packages (two package names, same library name). The ancient procps used libproc or libproc-a.b.c where a.b.c was the package version. Kept the revision numbers down (it was always 0.0.0) but the name of the library changed. So if we use libproc-2 is there a clash with an ancient procps? procps v 2.0.0 was around in 1999 so it was 22 years ago, also the name of the library would have been libproc-2.0.0.so not libproc-2.so so we're fine with that. libproc-2 seems to fit, our second major re-work of the procps library. Signed-off-by: Craig Small <csmall@dropbear.xyz>
2021-02-20 19:30:31 +08:00
proc/libproc-2.la
build-sys: install binaries in bindir (get rid of usrbin_execdir) The "usrbin_execdir" hack meant to install some binaries in /bin and others in /usr/bin. However: - It is very inflexible: not much control on the final directory name and it is not possible to get rid of the usr/bin suffix without patching the build system. - It is hard to use: it requires configure to receive --exec_prefix=/ and other settings do not make much sense. It is not very obvious that that setting needs to be passed and it takes a while to figure it out. - It produces garbage with the default setup: the default prefix of /usr/local ends up installing the binaries under /usr/local/usr/bin which does not make any sense. Furthermore, the requirement to split binaries in /bin and /usr/bin is not that strong since some distributions adopted the /usr merge and so would agree to just deploy all binaries to /usr/bin directly. Distributions that would still like to split /bin from /usr/bin should actually move binaries such as `ps` and `kill` to /bin after the install of procps-ng is complete. After all, they are the ones responsible for determining what are the binaries that need to be in the root partition and that list depends on their early boot init scripts, so it is possible that the list must be augmented with other binaries from this package. Therefore, I propose here to get rid of that hack and simply install all the binaries to bindir instead, which solves the problems described above and simplifies the build and install of procps-ng. Tested that it builds and both `make check` and `make distcheck` work. Tested that `make install` works and produces the expected tree, the only difference being the absence of the bogus /usr/local/usr/bin directory and now all binaries are merged into /usr/local/bin as expected. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 14:27:13 +08:00
build-sys: take autotools in use again This will revert change at Oct 2002 when autotools support was removed. Unlike before the package developers are expected to use ./autogen.sh to generate ./configure script, and run make after that. The build system is also able to create, with make dist, a tar ball release which compiles correctly, and has files which seemed to be important to have. The patch removes few unnecessary files, but no everything. Files procps.lsm and procps.spec in git repository are useless as is, but I left them lying around for someone who can make more justified call about removal of them. Last, but not least package version number is set 3.3.0 to distinct this procps from the sourceforge's upstream procps. Please notice that libproc relese is kept as 3.2.8. Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2011-06-04 22:26:58 +08:00
dist_man_MANS = \
free.1 \
pgrep.1 \
pkill.1 \
pmap.1 \
uptime.1 \
vmstat.8 \
build-sys: tweak Makefile.am for two preceding patches This commit cleans up some man document files. It also changes the target install directory from the original 'proc/' to 'procps/' (feels like a more natural name). [ and, now it agrees with those 2 preceding man docs ] [ since it is obvious the tail was wagging this dog! ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-06-22 13:00:00 +08:00
doc/procps.3 \
doc/procps_pids.3 \
build-sys: Remove refs to old manpage I removed the old man pages but didn't remove their references in the Makefile References: commit a978f68c06eb1764d401fa0ffce9fb30cd55f2e4 commit 770505ded42566b70fd0ee2cade98a317d18ac38 commit 7246249b8c2683c13515147ff4f9dbb85ba211ae
2020-12-22 08:27:17 +08:00
doc/procps_misc.3
build-sys: take autotools in use again This will revert change at Oct 2002 when autotools support was removed. Unlike before the package developers are expected to use ./autogen.sh to generate ./configure script, and run make after that. The build system is also able to create, with make dist, a tar ball release which compiles correctly, and has files which seemed to be important to have. The patch removes few unnecessary files, but no everything. Files procps.lsm and procps.spec in git repository are useless as is, but I left them lying around for someone who can make more justified call about removal of them. Last, but not least package version number is set 3.3.0 to distinct this procps from the sourceforge's upstream procps. Please notice that libproc relese is kept as 3.2.8. Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2011-06-04 22:26:58 +08:00
Port of merge request 49 to newlib Wayne Porter made !49 which added Cygwin support to the master branch This is the port of those changes to newlib
2017-08-19 21:05:22 +08:00
if !CYGWIN
dist_man_MANS += \
pwdx.1 \
tload.1 \
sysctl.8 \
sysctl.conf.5 \
ps/ps.1
pgrep: add pwait
2020-02-24 11:02:59 +08:00
pidwait: Rename from pwait pwait is already in at least Debian in a different package References: https://bugs.debian.org/982391
2021-02-15 18:10:06 +08:00
if BUILD_PIDWAIT
dist_man_MANS += pidwait.1
pgrep: add pwait
2020-02-24 11:02:59 +08:00
endif
Port of merge request 49 to newlib Wayne Porter made !49 which added Cygwin support to the master branch This is the port of those changes to newlib
2017-08-19 21:05:22 +08:00
endif
Makefile.am fixes Two problems. 1) skill/snice : distribution doesnt mean install If you don't set your configure flags right, you dont install the skill/snice man pages which means you will break any subsequent compiles with the flags enabled. Man pages not to be installed should still be distributed. 2) The git version into Makefile.am breaks under certain conditions. The easy break for this is: touch aclocal.m4 make We need this script added plus some dist hook magic that got left out.
2012-05-20 15:27:14 +08:00
EXTRA_DIST = \
build-sys: include .version in EXTRA_DIST .version is created in the top_srdir which when building normally doesn't present a problem. When make distcheck is run, the source directory is made read-only and it fails with permission denied. The version of misc/git-version-gen is old and is missing the instruction to add .version to EXTRA_DIST. This commit does just that. make distcheck now passes. References: https://github.com/gagern/gnulib/blob/master/build-aux/git-version-gen https://lists.gnu.org/archive/html/bug-gnulib/2011-08/msg00000.html Signed-off-by: Craig Small <csmall@enc.com.au>
2015-08-09 14:27:37 +08:00
.version \
Makefile.am fixes Two problems. 1) skill/snice : distribution doesnt mean install If you don't set your configure flags right, you dont install the skill/snice man pages which means you will break any subsequent compiles with the flags enabled. Man pages not to be installed should still be distributed. 2) The git version into Makefile.am breaks under certain conditions. The easy break for this is: touch aclocal.m4 make We need this script added plus some dist hook magic that got left out.
2012-05-20 15:27:14 +08:00
autogen.sh \
contrib \
COPYING.LIB \
misc/git-version-gen \
docs: Update filenames in Makefile too
2015-05-10 15:49:11 +08:00
Documentation/CodingStyle.md \
Makefile.am fixes Two problems. 1) skill/snice : distribution doesnt mean install If you don't set your configure flags right, you dont install the skill/snice man pages which means you will break any subsequent compiles with the flags enabled. Man pages not to be installed should still be distributed. 2) The git version into Makefile.am breaks under certain conditions. The easy break for this is: touch aclocal.m4 make We need this script added plus some dist hook magic that got left out.
2012-05-20 15:27:14 +08:00
Documentation/TODO \
build-sys: merge automake subdirs into toplevel This will be required for subdir-objects, otherwise automake will have problems with more than one Makefile.am having rules to build the same files. Tested that it builds and both `make check` and `make distcheck` work. Tested `make install` and compared the tree with the one installed before this commit, both installed the binaries to the same locations. The binaries are also in the same location in the build tree (for instance, ps/pscommand is still there.) Checked the binaries for the correct libraries linked into them. Binary sizes matched before and after this change. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:28:53 +08:00
ps/HACKING \
ps/regression \
Moved man-po pot file creation into Makefile The pot files for man-po are part of the extra_dist target so are built at dist time. These used to be created as part of the dist-hook. However it is better to control their builds in the Makefile so they are conditionally built. It also means distcheck doesn't complain when they are added to the CLEANFILES.
2014-06-25 21:11:15 +08:00
$(DIST_MAN_POTS)
Makefile.am fixes Two problems. 1) skill/snice : distribution doesnt mean install If you don't set your configure flags right, you dont install the skill/snice man pages which means you will break any subsequent compiles with the flags enabled. Man pages not to be installed should still be distributed. 2) The git version into Makefile.am breaks under certain conditions. The easy break for this is: touch aclocal.m4 make We need this script added plus some dist hook magic that got left out.
2012-05-20 15:27:14 +08:00
Port of merge request 49 to newlib Wayne Porter made !49 which added Cygwin support to the master branch This is the port of those changes to newlib
2017-08-19 21:05:22 +08:00
if !CYGWIN
EXTRA_DIST += \
sysctl.conf
endif
build-sys: merge automake subdirs into toplevel This will be required for subdir-objects, otherwise automake will have problems with more than one Makefile.am having rules to build the same files. Tested that it builds and both `make check` and `make distcheck` work. Tested `make install` and compared the tree with the one installed before this commit, both installed the binaries to the same locations. The binaries are also in the same location in the build tree (for instance, ps/pscommand is still there.) Checked the binaries for the correct libraries linked into them. Binary sizes matched before and after this change. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:28:53 +08:00
procpsngdir = $(docdir)
dist_procpsng_DATA = \
docs: Update filenames in Makefile too
2015-05-10 15:49:11 +08:00
Documentation/bugs.md \
library: created a valgrind 'warning-suppression' file Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-10-14 13:00:00 +08:00
Documentation/FAQ \
Documentation/libproc.supp
build-sys: merge automake subdirs into toplevel This will be required for subdir-objects, otherwise automake will have problems with more than one Makefile.am having rules to build the same files. Tested that it builds and both `make check` and `make distcheck` work. Tested `make install` and compared the tree with the one installed before this commit, both installed the binaries to the same locations. The binaries are also in the same location in the build tree (for instance, ps/pscommand is still there.) Checked the binaries for the correct libraries linked into them. Binary sizes matched before and after this change. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:28:53 +08:00
pidof: reimplemented from scratch (replacing sysvinit pidof) As the sysvinit becomes obsolete, some of the bundled tools need to find a new home. The procps-ng project seems to be the most suitable project for adopting the pidof tool. This commit introduces a redesigned version of pidof that satisfies the LSB requirements. In corner cases the behaviour might differ from the former one as the new version doesn't use any stat(2) calls.
2013-10-05 02:35:01 +08:00
if BUILD_PIDOF
Port of merge request 49 to newlib Wayne Porter made !49 which added Cygwin support to the master branch This is the port of those changes to newlib
2017-08-19 21:05:22 +08:00
if !CYGWIN
build-sys: install binaries in bindir (get rid of usrbin_execdir) The "usrbin_execdir" hack meant to install some binaries in /bin and others in /usr/bin. However: - It is very inflexible: not much control on the final directory name and it is not possible to get rid of the usr/bin suffix without patching the build system. - It is hard to use: it requires configure to receive --exec_prefix=/ and other settings do not make much sense. It is not very obvious that that setting needs to be passed and it takes a while to figure it out. - It produces garbage with the default setup: the default prefix of /usr/local ends up installing the binaries under /usr/local/usr/bin which does not make any sense. Furthermore, the requirement to split binaries in /bin and /usr/bin is not that strong since some distributions adopted the /usr merge and so would agree to just deploy all binaries to /usr/bin directly. Distributions that would still like to split /bin from /usr/bin should actually move binaries such as `ps` and `kill` to /bin after the install of procps-ng is complete. After all, they are the ones responsible for determining what are the binaries that need to be in the root partition and that list depends on their early boot init scripts, so it is possible that the list must be augmented with other binaries from this package. Therefore, I propose here to get rid of that hack and simply install all the binaries to bindir instead, which solves the problems described above and simplifies the build and install of procps-ng. Tested that it builds and both `make check` and `make distcheck` work. Tested that `make install` works and produces the expected tree, the only difference being the absence of the bogus /usr/local/usr/bin directory and now all binaries are merged into /usr/local/bin as expected. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 14:27:13 +08:00
bin_PROGRAMS += pidof
Port of merge request 49 to newlib Wayne Porter made !49 which added Cygwin support to the master branch This is the port of those changes to newlib
2017-08-19 21:05:22 +08:00
else
usrbin_exec_PROGRAMS += pidof
endif
pidof: reimplemented from scratch (replacing sysvinit pidof) As the sysvinit becomes obsolete, some of the bundled tools need to find a new home. The procps-ng project seems to be the most suitable project for adopting the pidof tool. This commit introduces a redesigned version of pidof that satisfies the LSB requirements. In corner cases the behaviour might differ from the former one as the new version doesn't use any stat(2) calls.
2013-10-05 02:35:01 +08:00
dist_man_MANS += pidof.1
build-sys: drop unneeded $(top_srcdir) from source paths This is cleaner and we need to match paths exactly when we enable the subdir-objects automake option. Out-of-tree builds still work since automake is smart to know these are source files and that it needs to look for them in $(top_srcdir), so there is no need to make this explicit. Tested that it builds and both `make check` and `make distcheck` work. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:36:40 +08:00
pidof_SOURCES = pidof.c lib/fileutils.c
pidof: reimplemented from scratch (replacing sysvinit pidof) As the sysvinit becomes obsolete, some of the bundled tools need to find a new home. The procps-ng project seems to be the most suitable project for adopting the pidof tool. This commit introduces a redesigned version of pidof that satisfies the LSB requirements. In corner cases the behaviour might differ from the former one as the new version doesn't use any stat(2) calls.
2013-10-05 02:35:01 +08:00
else
EXTRA_DIST += pidof.1
endif
build-sys: add --disable-kill build option The kill from procps-ng is not always wanted. For example RedHat seems to prefer kill from util-linux package. Reported-by: Jaromir Capik <jcapik@redhat.com> Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2011-10-05 02:16:46 +08:00
if BUILD_KILL
Port of merge request 49 to newlib Wayne Porter made !49 which added Cygwin support to the master branch This is the port of those changes to newlib
2017-08-19 21:05:22 +08:00
if CYGWIN
transform += ;s/^kill/prockill/; $(program_transform_name)
usrbin_exec_PROGRAMS += kill
else
build-sys: merge automake subdirs into toplevel This will be required for subdir-objects, otherwise automake will have problems with more than one Makefile.am having rules to build the same files. Tested that it builds and both `make check` and `make distcheck` work. Tested `make install` and compared the tree with the one installed before this commit, both installed the binaries to the same locations. The binaries are also in the same location in the build tree (for instance, ps/pscommand is still there.) Checked the binaries for the correct libraries linked into them. Binary sizes matched before and after this change. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:28:53 +08:00
bin_PROGRAMS += kill
Port of merge request 49 to newlib Wayne Porter made !49 which added Cygwin support to the master branch This is the port of those changes to newlib
2017-08-19 21:05:22 +08:00
endif
build-sys: add --disable-kill build option The kill from procps-ng is not always wanted. For example RedHat seems to prefer kill from util-linux package. Reported-by: Jaromir Capik <jcapik@redhat.com> Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2011-10-05 02:16:46 +08:00
dist_man_MANS += kill.1
kill: split out from skill/snice The first part of fixing skill/snice to use the library instead of directly readdir()ing /proc which is what it does now. Remove the kill code from the skill/snice code and put common elements into lib/signals.c Not 100% sure that is the right destination instead of a new lib file, but ok for now. kill shares some parsing logic with skill/snice but mainly around signal specifications. The "do it" code is very different. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-09-26 07:13:13 +08:00
kill_SOURCES = kill.c lib/strutils.c lib/fileutils.c lib/signals.c
misc: eliminate accumulated trailing whitespace, again Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-12-01 13:00:00 +08:00
kill_LDADD =
Makefile.am fixes Two problems. 1) skill/snice : distribution doesnt mean install If you don't set your configure flags right, you dont install the skill/snice man pages which means you will break any subsequent compiles with the flags enabled. Man pages not to be installed should still be distributed. 2) The git version into Makefile.am breaks under certain conditions. The easy break for this is: touch aclocal.m4 make We need this script added plus some dist hook magic that got left out.
2012-05-20 15:27:14 +08:00
else
EXTRA_DIST += kill.1
build-sys: add --disable-kill build option The kill from procps-ng is not always wanted. For example RedHat seems to prefer kill from util-linux package. Reported-by: Jaromir Capik <jcapik@redhat.com> Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2011-10-05 02:16:46 +08:00
endif
configure: Add --disable-w Some systems implement utmp as a stub so it doesn't make sense to have a non-functioning w. This change mitigates #193 and !126 References: procps-ng/procps!129 procps-ng/procps!126 procps-ng/procps#193
2021-04-24 03:58:36 +08:00
if BUILD_W
if CYGWIN
usrbin_exec_PROGRAMS += w
else
bin_PROGRAMS += w
endif
dist_man_MANS += w.1
w_SOURCES = w.c lib/fileutils.c
else
EXTRA_DIST += w.1
endif
ncurses and configure again Another fix to link properly to ncurses Some minor top fixes Added *~ to gitignore because these files crop up sometimes
2011-10-27 05:53:55 +08:00
if WITH_NCURSES
Port of merge request 49 to newlib Wayne Porter made !49 which added Cygwin support to the master branch This is the port of those changes to newlib
2017-08-19 21:05:22 +08:00
if !CYGWIN
build-sys: install binaries in bindir (get rid of usrbin_execdir) The "usrbin_execdir" hack meant to install some binaries in /bin and others in /usr/bin. However: - It is very inflexible: not much control on the final directory name and it is not possible to get rid of the usr/bin suffix without patching the build system. - It is hard to use: it requires configure to receive --exec_prefix=/ and other settings do not make much sense. It is not very obvious that that setting needs to be passed and it takes a while to figure it out. - It produces garbage with the default setup: the default prefix of /usr/local ends up installing the binaries under /usr/local/usr/bin which does not make any sense. Furthermore, the requirement to split binaries in /bin and /usr/bin is not that strong since some distributions adopted the /usr merge and so would agree to just deploy all binaries to /usr/bin directly. Distributions that would still like to split /bin from /usr/bin should actually move binaries such as `ps` and `kill` to /bin after the install of procps-ng is complete. After all, they are the ones responsible for determining what are the binaries that need to be in the root partition and that list depends on their early boot init scripts, so it is possible that the list must be augmented with other binaries from this package. Therefore, I propose here to get rid of that hack and simply install all the binaries to bindir instead, which solves the problems described above and simplifies the build and install of procps-ng. Tested that it builds and both `make check` and `make distcheck` work. Tested that `make install` works and produces the expected tree, the only difference being the absence of the bogus /usr/local/usr/bin directory and now all binaries are merged into /usr/local/bin as expected. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 14:27:13 +08:00
bin_PROGRAMS += \
build-sys: merge automake subdirs into toplevel This will be required for subdir-objects, otherwise automake will have problems with more than one Makefile.am having rules to build the same files. Tested that it builds and both `make check` and `make distcheck` work. Tested `make install` and compared the tree with the one installed before this commit, both installed the binaries to the same locations. The binaries are also in the same location in the build tree (for instance, ps/pscommand is still there.) Checked the binaries for the correct libraries linked into them. Binary sizes matched before and after this change. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:28:53 +08:00
watch \
top/top
Port of merge request 49 to newlib Wayne Porter made !49 which added Cygwin support to the master branch This is the port of those changes to newlib
2017-08-19 21:05:22 +08:00
else
usrbin_exec_PROGRAMS += \
watch \
top/top
endif
build-sys: take autotools in use again This will revert change at Oct 2002 when autotools support was removed. Unlike before the package developers are expected to use ./autogen.sh to generate ./configure script, and run make after that. The build system is also able to create, with make dist, a tar ball release which compiles correctly, and has files which seemed to be important to have. The patch removes few unnecessary files, but no everything. Files procps.lsm and procps.spec in git repository are useless as is, but I left them lying around for someone who can make more justified call about removal of them. Last, but not least package version number is set 3.3.0 to distinct this procps from the sourceforge's upstream procps. Please notice that libproc relese is kept as 3.2.8. Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2011-06-04 22:26:58 +08:00
dist_man_MANS += \
build-sys: merge automake subdirs into toplevel This will be required for subdir-objects, otherwise automake will have problems with more than one Makefile.am having rules to build the same files. Tested that it builds and both `make check` and `make distcheck` work. Tested `make install` and compared the tree with the one installed before this commit, both installed the binaries to the same locations. The binaries are also in the same location in the build tree (for instance, ps/pscommand is still there.) Checked the binaries for the correct libraries linked into them. Binary sizes matched before and after this change. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:28:53 +08:00
watch.1 \
top/top.1
Port of merge request 49 to newlib Wayne Porter made !49 which added Cygwin support to the master branch This is the port of those changes to newlib
2017-08-19 21:05:22 +08:00
if !CYGWIN
bin_PROGRAMS += \
slabtop
dist_man_MANS += \
slabtop.1
build-sys: drop unneeded $(top_srcdir) from source paths This is cleaner and we need to match paths exactly when we enable the subdir-objects automake option. Out-of-tree builds still work since automake is smart to know these are source files and that it needs to look for them in $(top_srcdir), so there is no need to make this explicit. Tested that it builds and both `make check` and `make distcheck` work. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:36:40 +08:00
slabtop_SOURCES = slabtop.c lib/strutils.c lib/fileutils.c
build-sys: use proper dependencies on libproc.la Use LDADD or *_LDADD instead of AM_LDFLAGS to refer to libproc.la. Otherwise, parallel builds will break as there is no explicit dependency to ensure the library is built before the binaries that try to link to it. v2: Added empty rules lib_test_*_LDADD to remove the dependency on libproc which is not used by the lib/test_* binaries. Tested by running `make -jNN` repeatedly for different levels of parallelism to ensure the build works. Also checked that `make check` and `make distcheck` still work as expected. Also made sure that a parallel make invocation works with `make -j distcheck`. Reported-by: Jim Warner <james.warner@comcast.net> Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-12 03:31:59 +08:00
slabtop_LDADD = $(LDADD) @NCURSES_LIBS@
Port of merge request 49 to newlib Wayne Porter made !49 which added Cygwin support to the master branch This is the port of those changes to newlib
2017-08-19 21:05:22 +08:00
endif
build-sys: drop unneeded $(top_srcdir) from source paths This is cleaner and we need to match paths exactly when we enable the subdir-objects automake option. Out-of-tree builds still work since automake is smart to know these are source files and that it needs to look for them in $(top_srcdir), so there is no need to make this explicit. Tested that it builds and both `make check` and `make distcheck` work. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:36:40 +08:00
watch_SOURCES = watch.c lib/strutils.c lib/fileutils.c
Added Cygwin build support strverscmp is included to satisfy a dependency in Cygwin. Excluded utmp and prctl functions that are not supported currently.
2016-03-11 07:04:27 +08:00
watch_LDADD = @WATCH_NCURSES_LIBS@ $(CYGWINFLAGS)
build-sys: merge automake subdirs into toplevel This will be required for subdir-objects, otherwise automake will have problems with more than one Makefile.am having rules to build the same files. Tested that it builds and both `make check` and `make distcheck` work. Tested `make install` and compared the tree with the one installed before this commit, both installed the binaries to the same locations. The binaries are also in the same location in the build tree (for instance, ps/pscommand is still there.) Checked the binaries for the correct libraries linked into them. Binary sizes matched before and after this change. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:28:53 +08:00
top_top_SOURCES = \
top/top.h \
top/top.c \
top/top_nls.h \
top/top_nls.c \
library: Update uptime calls to standard format Changed all the uptime related functions to use the standard naming procps_uptime_*
2015-06-29 20:09:59 +08:00
lib/fileutils.c \
library: Remove signal name from library Procps library previously held functions that were about either listing or finding signal names. These are not really the right location for a library about reading procfs. This patch handles signal related functions in two ways: For functions purely found in skill, these have been moved back into this binary as they are used nowhere else. For functions used across the binaries, these have been moved into include/signals.h and lib/signals.c. Besides formatting, these functions are largely the same. To assist the skill functions, two functions to access the signal map array have been added to lib/signals.c
2015-06-29 19:52:51 +08:00
lib/signals.c
Added Cygwin build support strverscmp is included to satisfy a dependency in Cygwin. Excluded utmp and prctl functions that are not supported currently.
2016-03-11 07:04:27 +08:00
if CYGWIN
Port of merge request 49 to newlib Wayne Porter made !49 which added Cygwin support to the master branch This is the port of those changes to newlib
2017-08-19 21:05:22 +08:00
top_top_SOURCES += lib/strverscmp.c
Added Cygwin build support strverscmp is included to satisfy a dependency in Cygwin. Excluded utmp and prctl functions that are not supported currently.
2016-03-11 07:04:27 +08:00
endif
build-sys: use proper dependencies on libproc.la Use LDADD or *_LDADD instead of AM_LDFLAGS to refer to libproc.la. Otherwise, parallel builds will break as there is no explicit dependency to ensure the library is built before the binaries that try to link to it. v2: Added empty rules lib_test_*_LDADD to remove the dependency on libproc which is not used by the lib/test_* binaries. Tested by running `make -jNN` repeatedly for different levels of parallelism to ensure the build works. Also checked that `make check` and `make distcheck` still work as expected. Also made sure that a parallel make invocation works with `make -j distcheck`. Reported-by: Jim Warner <james.warner@comcast.net> Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-12 03:31:59 +08:00
top_top_LDADD = $(LDADD) @NCURSES_LIBS@ $(DL_LIB)
build-sys: take autotools in use again This will revert change at Oct 2002 when autotools support was removed. Unlike before the package developers are expected to use ./autogen.sh to generate ./configure script, and run make after that. The build system is also able to create, with make dist, a tar ball release which compiles correctly, and has files which seemed to be important to have. The patch removes few unnecessary files, but no everything. Files procps.lsm and procps.spec in git repository are useless as is, but I left them lying around for someone who can make more justified call about removal of them. Last, but not least package version number is set 3.3.0 to distinct this procps from the sourceforge's upstream procps. Please notice that libproc relese is kept as 3.2.8. Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2011-06-04 22:26:58 +08:00
endif
skill, snice: do not encourage building these utilities Both skill and snice are are mentioned in manual page to be 'obsolete and unportable'. This commit discourages distributors to keep these commands part of default system. Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2012-03-16 04:29:13 +08:00
if BUILD_SKILL
Port of merge request 49 to newlib Wayne Porter made !49 which added Cygwin support to the master branch This is the port of those changes to newlib
2017-08-19 21:05:22 +08:00
if !CYGWIN
build-sys: install binaries in bindir (get rid of usrbin_execdir) The "usrbin_execdir" hack meant to install some binaries in /bin and others in /usr/bin. However: - It is very inflexible: not much control on the final directory name and it is not possible to get rid of the usr/bin suffix without patching the build system. - It is hard to use: it requires configure to receive --exec_prefix=/ and other settings do not make much sense. It is not very obvious that that setting needs to be passed and it takes a while to figure it out. - It produces garbage with the default setup: the default prefix of /usr/local ends up installing the binaries under /usr/local/usr/bin which does not make any sense. Furthermore, the requirement to split binaries in /bin and /usr/bin is not that strong since some distributions adopted the /usr merge and so would agree to just deploy all binaries to /usr/bin directly. Distributions that would still like to split /bin from /usr/bin should actually move binaries such as `ps` and `kill` to /bin after the install of procps-ng is complete. After all, they are the ones responsible for determining what are the binaries that need to be in the root partition and that list depends on their early boot init scripts, so it is possible that the list must be augmented with other binaries from this package. Therefore, I propose here to get rid of that hack and simply install all the binaries to bindir instead, which solves the problems described above and simplifies the build and install of procps-ng. Tested that it builds and both `make check` and `make distcheck` work. Tested that `make install` works and produces the expected tree, the only difference being the absence of the bogus /usr/local/usr/bin directory and now all binaries are merged into /usr/local/bin as expected. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 14:27:13 +08:00
bin_PROGRAMS += \
skill, snice: do not encourage building these utilities Both skill and snice are are mentioned in manual page to be 'obsolete and unportable'. This commit discourages distributors to keep these commands part of default system. Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2012-03-16 04:29:13 +08:00
skill \
snice
Port of merge request 49 to newlib Wayne Porter made !49 which added Cygwin support to the master branch This is the port of those changes to newlib
2017-08-19 21:05:22 +08:00
else
usrbin_exec_PROGRAMS += \
skill \
snice
endif
library: rework namespace calls Functions related to namespaces were half-in half-out of the procps library and didn't fit the standard naming scheme. While struct { long ns[x]} is a bit clunky, its the only way to "lock in" x. The alternative is to use ns_* variables. This work was needed before pgrep could be converted.
2015-09-03 20:32:19 +08:00
skill_SOURCES = skill.c lib/strutils.c lib/fileutils.c lib/signals.c
snice_SOURCES = skill.c lib/strutils.c lib/fileutils.c lib/signals.c
skill, snice: do not encourage building these utilities Both skill and snice are are mentioned in manual page to be 'obsolete and unportable'. This commit discourages distributors to keep these commands part of default system. Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2012-03-16 04:29:13 +08:00
dist_man_MANS += \
skill.1 \
snice.1
Makefile.am fixes Two problems. 1) skill/snice : distribution doesnt mean install If you don't set your configure flags right, you dont install the skill/snice man pages which means you will break any subsequent compiles with the flags enabled. Man pages not to be installed should still be distributed. 2) The git version into Makefile.am breaks under certain conditions. The easy break for this is: touch aclocal.m4 make We need this script added plus some dist hook magic that got left out.
2012-05-20 15:27:14 +08:00
else
EXTRA_DIST += \
skill.1 \
snice.1
skill, snice: do not encourage building these utilities Both skill and snice are are mentioned in manual page to be 'obsolete and unportable'. This commit discourages distributors to keep these commands part of default system. Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2012-03-16 04:29:13 +08:00
endif
build-sys: drop unneeded $(top_srcdir) from source paths This is cleaner and we need to match paths exactly when we enable the subdir-objects automake option. Out-of-tree builds still work since automake is smart to know these are source files and that it needs to look for them in $(top_srcdir), so there is no need to make this explicit. Tested that it builds and both `make check` and `make distcheck` work. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:36:40 +08:00
free_SOURCES = free.c lib/strutils.c lib/fileutils.c
library: rework namespace calls Functions related to namespaces were half-in half-out of the procps library and didn't fit the standard naming scheme. While struct { long ns[x]} is a bit clunky, its the only way to "lock in" x. The alternative is to use ns_* variables. This work was needed before pgrep could be converted.
2015-09-03 20:32:19 +08:00
pgrep_SOURCES = pgrep.c lib/fileutils.c lib/signals.c
pkill_SOURCES = pgrep.c lib/fileutils.c lib/signals.c
build-sys: drop unneeded $(top_srcdir) from source paths This is cleaner and we need to match paths exactly when we enable the subdir-objects automake option. Out-of-tree builds still work since automake is smart to know these are source files and that it needs to look for them in $(top_srcdir), so there is no need to make this explicit. Tested that it builds and both `make check` and `make distcheck` work. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:36:40 +08:00
pmap_SOURCES = pmap.c lib/fileutils.c
pidwait: Rename from pwait pwait is already in at least Debian in a different package References: https://bugs.debian.org/982391
2021-02-15 18:10:06 +08:00
if BUILD_PIDWAIT
pidwait_SOURCES = pgrep.c lib/fileutils.c lib/signals.c
pgrep: add pwait
2020-02-24 11:02:59 +08:00
endif
Port of merge request 49 to newlib Wayne Porter made !49 which added Cygwin support to the master branch This is the port of those changes to newlib
2017-08-19 21:05:22 +08:00
if !CYGWIN
build-sys: drop unneeded $(top_srcdir) from source paths This is cleaner and we need to match paths exactly when we enable the subdir-objects automake option. Out-of-tree builds still work since automake is smart to know these are source files and that it needs to look for them in $(top_srcdir), so there is no need to make this explicit. Tested that it builds and both `make check` and `make distcheck` work. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:36:40 +08:00
pwdx_SOURCES = pwdx.c lib/fileutils.c
Added Cygwin build support strverscmp is included to satisfy a dependency in Cygwin. Excluded utmp and prctl functions that are not supported currently.
2016-03-11 07:04:27 +08:00
pwdx_LDADD= $(CYGWINFLAGS)
sysctl: Bring procio functions out of library The procio functions that were in the library have been moved into sysctl. sysctl is not linked to libprocps in newlib and none of the other procps binaries would need to read/write large data to the procfs. References: be6b048a41b0a47ebed602d9e0993fe18c9de237
2018-03-01 18:25:04 +08:00
sysctl_SOURCES = \
sysctl.c \
lib/fileutils.c \
sysctl: relocate the procio code to a more proper home Now that the procio logic was removed from the library we must move the header file, lest we break make dist. In the process, we will relocate that source file too. [ we'll take a slightly different approach than that ] [ used under the master branch by exploiting those 2 ] [ non-library directories 'include' and 'lib', while ] [ avoiding any sysctl hard coded function prototype. ] Signed-off-by: Jim Warner <james.warner@comcast.net>
2018-04-01 14:00:00 +08:00
lib/procio.c
sysctl: Remove links to library sysctl doesn't use any symbols from the libprocps library so this update removes those dependencies.
2015-09-01 18:57:56 +08:00
sysctl_LDADD=
Port of merge request 49 to newlib Wayne Porter made !49 which added Cygwin support to the master branch This is the port of those changes to newlib
2017-08-19 21:05:22 +08:00
endif
build-sys: drop unneeded $(top_srcdir) from source paths This is cleaner and we need to match paths exactly when we enable the subdir-objects automake option. Out-of-tree builds still work since automake is smart to know these are source files and that it needs to look for them in $(top_srcdir), so there is no need to make this explicit. Tested that it builds and both `make check` and `make distcheck` work. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:36:40 +08:00
tload_SOURCES = tload.c lib/strutils.c lib/fileutils.c
uptime_SOURCES = uptime.c lib/fileutils.c
vmstat_SOURCES = vmstat.c lib/strutils.c lib/fileutils.c
build-sys: take autotools in use again This will revert change at Oct 2002 when autotools support was removed. Unlike before the package developers are expected to use ./autogen.sh to generate ./configure script, and run make after that. The build system is also able to create, with make dist, a tar ball release which compiles correctly, and has files which seemed to be important to have. The patch removes few unnecessary files, but no everything. Files procps.lsm and procps.spec in git repository are useless as is, but I left them lying around for someone who can make more justified call about removal of them. Last, but not least package version number is set 3.3.0 to distinct this procps from the sourceforge's upstream procps. Please notice that libproc relese is kept as 3.2.8. Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2011-06-04 22:26:58 +08:00
build-sys: merge automake subdirs into toplevel This will be required for subdir-objects, otherwise automake will have problems with more than one Makefile.am having rules to build the same files. Tested that it builds and both `make check` and `make distcheck` work. Tested `make install` and compared the tree with the one installed before this commit, both installed the binaries to the same locations. The binaries are also in the same location in the build tree (for instance, ps/pscommand is still there.) Checked the binaries for the correct libraries linked into them. Binary sizes matched before and after this change. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:28:53 +08:00
# See http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
library: Rename to libproc-2 What to call the new library? Keep using libprocps wouldn't do, its a very different library from the programs' point of view. It would also mean we could have some clashes around the packages (two package names, same library name). The ancient procps used libproc or libproc-a.b.c where a.b.c was the package version. Kept the revision numbers down (it was always 0.0.0) but the name of the library changed. So if we use libproc-2 is there a clash with an ancient procps? procps v 2.0.0 was around in 1999 so it was 22 years ago, also the name of the library would have been libproc-2.0.0.so not libproc-2.so so we're fine with that. libproc-2 seems to fit, our second major re-work of the procps library. Signed-off-by: Craig Small <csmall@dropbear.xyz>
2021-02-20 19:30:31 +08:00
LIBproc_2_CURRENT=0
LIBproc_2_REVISION=0
LIBproc_2_AGE=0
build-sys: merge automake subdirs into toplevel This will be required for subdir-objects, otherwise automake will have problems with more than one Makefile.am having rules to build the same files. Tested that it builds and both `make check` and `make distcheck` work. Tested `make install` and compared the tree with the one installed before this commit, both installed the binaries to the same locations. The binaries are also in the same location in the build tree (for instance, ps/pscommand is still there.) Checked the binaries for the correct libraries linked into them. Binary sizes matched before and after this change. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:28:53 +08:00
library: Rename to libproc-2 What to call the new library? Keep using libprocps wouldn't do, its a very different library from the programs' point of view. It would also mean we could have some clashes around the packages (two package names, same library name). The ancient procps used libproc or libproc-a.b.c where a.b.c was the package version. Kept the revision numbers down (it was always 0.0.0) but the name of the library changed. So if we use libproc-2 is there a clash with an ancient procps? procps v 2.0.0 was around in 1999 so it was 22 years ago, also the name of the library would have been libproc-2.0.0.so not libproc-2.so so we're fine with that. libproc-2 seems to fit, our second major re-work of the procps library. Signed-off-by: Craig Small <csmall@dropbear.xyz>
2021-02-20 19:30:31 +08:00
proc_libproc_2_la_LIBADD = $(LIB_KPARTS)
build-sys: merge automake subdirs into toplevel This will be required for subdir-objects, otherwise automake will have problems with more than one Makefile.am having rules to build the same files. Tested that it builds and both `make check` and `make distcheck` work. Tested `make install` and compared the tree with the one installed before this commit, both installed the binaries to the same locations. The binaries are also in the same location in the build tree (for instance, ps/pscommand is still there.) Checked the binaries for the correct libraries linked into them. Binary sizes matched before and after this change. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:28:53 +08:00
if WITH_SYSTEMD
library: Rename to libproc-2 What to call the new library? Keep using libprocps wouldn't do, its a very different library from the programs' point of view. It would also mean we could have some clashes around the packages (two package names, same library name). The ancient procps used libproc or libproc-a.b.c where a.b.c was the package version. Kept the revision numbers down (it was always 0.0.0) but the name of the library changed. So if we use libproc-2 is there a clash with an ancient procps? procps v 2.0.0 was around in 1999 so it was 22 years ago, also the name of the library would have been libproc-2.0.0.so not libproc-2.so so we're fine with that. libproc-2 seems to fit, our second major re-work of the procps library. Signed-off-by: Craig Small <csmall@dropbear.xyz>
2021-02-20 19:30:31 +08:00
proc_libproc_2_la_LIBADD += @SYSTEMD_LIBS@
build-sys: merge automake subdirs into toplevel This will be required for subdir-objects, otherwise automake will have problems with more than one Makefile.am having rules to build the same files. Tested that it builds and both `make check` and `make distcheck` work. Tested `make install` and compared the tree with the one installed before this commit, both installed the binaries to the same locations. The binaries are also in the same location in the build tree (for instance, ps/pscommand is still there.) Checked the binaries for the correct libraries linked into them. Binary sizes matched before and after this change. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:28:53 +08:00
endif
library: Rename to libproc-2 What to call the new library? Keep using libprocps wouldn't do, its a very different library from the programs' point of view. It would also mean we could have some clashes around the packages (two package names, same library name). The ancient procps used libproc or libproc-a.b.c where a.b.c was the package version. Kept the revision numbers down (it was always 0.0.0) but the name of the library changed. So if we use libproc-2 is there a clash with an ancient procps? procps v 2.0.0 was around in 1999 so it was 22 years ago, also the name of the library would have been libproc-2.0.0.so not libproc-2.so so we're fine with that. libproc-2 seems to fit, our second major re-work of the procps library. Signed-off-by: Craig Small <csmall@dropbear.xyz>
2021-02-20 19:30:31 +08:00
proc_libproc_2_la_LDFLAGS = \
-version-info $(LIBproc_2_CURRENT):$(LIBproc_2_REVISION):$(LIBproc_2_AGE) \
build-sys: merge automake subdirs into toplevel This will be required for subdir-objects, otherwise automake will have problems with more than one Makefile.am having rules to build the same files. Tested that it builds and both `make check` and `make distcheck` work. Tested `make install` and compared the tree with the one installed before this commit, both installed the binaries to the same locations. The binaries are also in the same location in the build tree (for instance, ps/pscommand is still there.) Checked the binaries for the correct libraries linked into them. Binary sizes matched before and after this change. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:28:53 +08:00
-no-undefined \
library: Rename to libproc-2 What to call the new library? Keep using libprocps wouldn't do, its a very different library from the programs' point of view. It would also mean we could have some clashes around the packages (two package names, same library name). The ancient procps used libproc or libproc-a.b.c where a.b.c was the package version. Kept the revision numbers down (it was always 0.0.0) but the name of the library changed. So if we use libproc-2 is there a clash with an ancient procps? procps v 2.0.0 was around in 1999 so it was 22 years ago, also the name of the library would have been libproc-2.0.0.so not libproc-2.so so we're fine with that. libproc-2 seems to fit, our second major re-work of the procps library. Signed-off-by: Craig Small <csmall@dropbear.xyz>
2021-02-20 19:30:31 +08:00
-Wl,--version-script=$(top_srcdir)/proc/libproc-2.sym
build-sys: merge automake subdirs into toplevel This will be required for subdir-objects, otherwise automake will have problems with more than one Makefile.am having rules to build the same files. Tested that it builds and both `make check` and `make distcheck` work. Tested `make install` and compared the tree with the one installed before this commit, both installed the binaries to the same locations. The binaries are also in the same location in the build tree (for instance, ps/pscommand is still there.) Checked the binaries for the correct libraries linked into them. Binary sizes matched before and after this change. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:28:53 +08:00
library: Rename to libproc-2 What to call the new library? Keep using libprocps wouldn't do, its a very different library from the programs' point of view. It would also mean we could have some clashes around the packages (two package names, same library name). The ancient procps used libproc or libproc-a.b.c where a.b.c was the package version. Kept the revision numbers down (it was always 0.0.0) but the name of the library changed. So if we use libproc-2 is there a clash with an ancient procps? procps v 2.0.0 was around in 1999 so it was 22 years ago, also the name of the library would have been libproc-2.0.0.so not libproc-2.so so we're fine with that. libproc-2 seems to fit, our second major re-work of the procps library. Signed-off-by: Craig Small <csmall@dropbear.xyz>
2021-02-20 19:30:31 +08:00
proc_libproc_2_la_SOURCES = \
build-sys: merge automake subdirs into toplevel This will be required for subdir-objects, otherwise automake will have problems with more than one Makefile.am having rules to build the same files. Tested that it builds and both `make check` and `make distcheck` work. Tested `make install` and compared the tree with the one installed before this commit, both installed the binaries to the same locations. The binaries are also in the same location in the build tree (for instance, ps/pscommand is still there.) Checked the binaries for the correct libraries linked into them. Binary sizes matched before and after this change. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:28:53 +08:00
proc/devname.c \
proc/devname.h \
library: rename 'diskstat' source as 'diskstats' files Where possible, libprocps files convey the name of the actual source pseudo file under the '/proc' directory. This brings diskstats into line with such an approach. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-20 13:00:00 +08:00
proc/diskstats.c \
proc/diskstats.h \
build-sys: merge automake subdirs into toplevel This will be required for subdir-objects, otherwise automake will have problems with more than one Makefile.am having rules to build the same files. Tested that it builds and both `make check` and `make distcheck` work. Tested `make install` and compared the tree with the one installed before this commit, both installed the binaries to the same locations. The binaries are also in the same location in the build tree (for instance, ps/pscommand is still there.) Checked the binaries for the correct libraries linked into them. Binary sizes matched before and after this change. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:28:53 +08:00
proc/escape.c \
proc/escape.h \
build-sys: fix oversight for a newly added header file Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-19 21:34:12 +08:00
proc/procps-private.h \
library: Add procps_meminfo_* functions New set of functions that read the /proc/meminfo file. Still needs work.
2015-06-20 21:08:47 +08:00
proc/meminfo.c \
proc/meminfo.h \
all: make buildable again for new 'misc.h' header file With the 4 header files removed in the previous patch, this commit just changes all those obsolete references to that new consolidated 'misc.h' header file instead. Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-01-19 14:00:00 +08:00
proc/misc.h \
library: rework namespace calls Functions related to namespaces were half-in half-out of the procps library and didn't fit the standard naming scheme. While struct { long ns[x]} is a bit clunky, its the only way to "lock in" x. The alternative is to use ns_* variables. This work was needed before pgrep could be converted.
2015-09-03 20:32:19 +08:00
proc/namespace.c \
library: set stage for NUMA node field display support In response to that suggestion referenced below, these changes allow display of task/thread level NUMA nodes. Currently, only the 'top' program offers any NUMA type support and it is limited to the Summary Area display. With this commit both the 'top' and 'ps' programs will be able to display NUMA nodes associated with threads. Reference(s): https://gitlab.com/procps-ng/procps/issues/58 Signed-off-by: Jim Warner <james.warner@comcast.net>
2017-05-12 13:03:00 +08:00
proc/numa.c \
proc/numa.h \
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 13:00:00 +08:00
proc/pids.c \
proc/pids.h \
build-sys: merge automake subdirs into toplevel This will be required for subdir-objects, otherwise automake will have problems with more than one Makefile.am having rules to build the same files. Tested that it builds and both `make check` and `make distcheck` work. Tested `make install` and compared the tree with the one installed before this commit, both installed the binaries to the same locations. The binaries are also in the same location in the build tree (for instance, ps/pscommand is still there.) Checked the binaries for the correct libraries linked into them. Binary sizes matched before and after this change. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:28:53 +08:00
proc/pwcache.c \
proc/pwcache.h \
proc/readproc.c \
proc/readproc.h \
library: rename the 'slab' sources as 'slabinfo' files Where possible, libprocps files convey the name of the actual source pseudo file under the '/proc' directory. This patch brings slab into line with such a standard. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 13:00:00 +08:00
proc/slabinfo.c \
proc/slabinfo.h \
library: rename those readstat.c & h sources to 'stat' In an attempt to normalize the 'stat' interface, we'll first shed any reminders of the old readproc interface by changing file names to be more descriptive & brief. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-04-25 13:00:00 +08:00
proc/stat.c \
proc/stat.h \
build-sys: merge automake subdirs into toplevel This will be required for subdir-objects, otherwise automake will have problems with more than one Makefile.am having rules to build the same files. Tested that it builds and both `make check` and `make distcheck` work. Tested `make install` and compared the tree with the one installed before this commit, both installed the binaries to the same locations. The binaries are also in the same location in the build tree (for instance, ps/pscommand is still there.) Checked the binaries for the correct libraries linked into them. Binary sizes matched before and after this change. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:28:53 +08:00
proc/sysinfo.c \
proc/version.c \
library: sysstat and vmstat api changes Use the standard libc declarations. For protecting the headers for C++ procps used to have its own defines, this change makes them use the standard libc ones. getstat() -> procps_stat_* vminfo() -> procps_vmstat_* These two components of the library now use the newer version of the API with less exposed global variables. The old methods are there for now. Signed-off-by: Craig Small <csmall@enc.com.au>
2015-06-20 05:43:02 +08:00
proc/vmstat.c \
proc/vmstat.h \
library: refactor and rely on modern kernels for wchan Several Debian based distributions were recently found to have omitted a kernel configuration option that had the effect of rendering /proc/#/stat and /proc/#/wchan useless for providing any 'sleeping in function' info. That problem also prompted a reevaluation of the whole approach to wchan matters which had grown increasingly complex as our library evolved over the last 13 years. The net result was a decision to rely on /proc/#/wchan which arrived along with the 2.5 kernel. This then let us vastly simplify the internal code plus the external interface which will benefit both the top and ps pgms. Reference(s): http://www.freelists.org/post/procps/WCHAN,11 https://lkml.org/lkml/2008/11/6/12 https://bugs.debian.org/711592 Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-06-18 13:00:00 +08:00
proc/wchan.c \
build-sys: merge automake subdirs into toplevel This will be required for subdir-objects, otherwise automake will have problems with more than one Makefile.am having rules to build the same files. Tested that it builds and both `make check` and `make distcheck` work. Tested `make install` and compared the tree with the one installed before this commit, both installed the binaries to the same locations. The binaries are also in the same location in the build tree (for instance, ps/pscommand is still there.) Checked the binaries for the correct libraries linked into them. Binary sizes matched before and after this change. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:28:53 +08:00
proc/wchan.h \
library: memory and vmstat API changes Created new set of functions for meminfo related calls. Liked the format of that better so changed vmstat around so the look similar. Missed the makefile change for uptime so added it in now.
2015-06-21 16:22:28 +08:00
proc/uptime.c \
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 13:00:00 +08:00
proc/xtra-procps-debug.h
build-sys: merge automake subdirs into toplevel This will be required for subdir-objects, otherwise automake will have problems with more than one Makefile.am having rules to build the same files. Tested that it builds and both `make check` and `make distcheck` work. Tested `make install` and compared the tree with the one installed before this commit, both installed the binaries to the same locations. The binaries are also in the same location in the build tree (for instance, ps/pscommand is still there.) Checked the binaries for the correct libraries linked into them. Binary sizes matched before and after this change. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:28:53 +08:00
library: Rename to libproc-2 What to call the new library? Keep using libprocps wouldn't do, its a very different library from the programs' point of view. It would also mean we could have some clashes around the packages (two package names, same library name). The ancient procps used libproc or libproc-a.b.c where a.b.c was the package version. Kept the revision numbers down (it was always 0.0.0) but the name of the library changed. So if we use libproc-2 is there a clash with an ancient procps? procps v 2.0.0 was around in 1999 so it was 22 years ago, also the name of the library would have been libproc-2.0.0.so not libproc-2.so so we're fine with that. libproc-2 seems to fit, our second major re-work of the procps library. Signed-off-by: Craig Small <csmall@dropbear.xyz>
2021-02-20 19:30:31 +08:00
proc_libproc_2_la_includedir = $(includedir)/procps/
proc_libproc_2_la_include_HEADERS = \
library: rename 'diskstat' source as 'diskstats' files Where possible, libprocps files convey the name of the actual source pseudo file under the '/proc' directory. This brings diskstats into line with such an approach. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-07-20 13:00:00 +08:00
proc/diskstats.h \
Install some missing header files required by procps.h
2017-08-14 02:45:12 +08:00
proc/meminfo.h \
all: make buildable again for new 'misc.h' header file With the 4 header files removed in the previous patch, this commit just changes all those obsolete references to that new consolidated 'misc.h' header file instead. Signed-off-by: Jim Warner <james.warner@comcast.net>
2021-01-19 14:00:00 +08:00
proc/misc.h \
library: implement task/thread support via the new api This commit is the culmination of efforts to modernize the library api. It should be treated as a first blush attempt, especially since I have absolutely no library design experience. But I did have a very strong desire to lessen the new library's impact on the top program. Under this new api, a 'stack' is the equivalent of the old proc_t. It can be seen as a variable length record whose contents & order is under complete user control. That initial stack/record configuration is established at procps_pids_new() time and will probably serve most program needs. But, a dynamic & demanding program like top will later change a stack via procps_pids_reset(). For programs like top & ps, procps_pids_reap() will be the function that will retrieve all tasks and threads. Any program that needs to filter / select only certain processes or users have available other functions that can be used: procps_pids_stacks_alloc, fill & dealloc. This implementation attempts to maximize that existing proven libprocps code base. As we gain more experience such actual code can be migrated into the pids.c file. Signed-off-by: Jim Warner <james.warner@comcast.net>
2015-08-19 13:00:00 +08:00
proc/pids.h \
library: rename the 'slab' sources as 'slabinfo' files Where possible, libprocps files convey the name of the actual source pseudo file under the '/proc' directory. This patch brings slab into line with such a standard. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-06-05 13:00:00 +08:00
proc/slabinfo.h \
Install some missing header files required by procps.h
2017-08-14 02:45:12 +08:00
proc/stat.h \
library: Fix up stat API Adjusted vmstat to use the new API for memory and CPU statistics
2015-06-23 20:22:50 +08:00
proc/vmstat.h \
library: provide for validating result type references During development, we now have a means for validating that a type referenced in application code matches the actual type set by the library. The new feature can be activated through either of the following two methods: 1) ./configure CFLAGS='-DXTRA_PROCPS_DEBUG' (all pgms) 2) an #include <proc/xtra-procps-debug.h> (single pgm) [ in the future, one could add a formal configure.ac ] [ provision. but for now a manual approach is safer. ] Lastly, for any module which provides a sort function, the handling for both 'noop' & 'extra' enumerators was made consistent. Now, 'noop' is not sorted and 'extra' will be sorted as that module's widest supported type. Signed-off-by: Jim Warner <james.warner@comcast.net>
2016-08-05 13:00:00 +08:00
proc/xtra-procps-debug.h
build-sys: merge automake subdirs into toplevel This will be required for subdir-objects, otherwise automake will have problems with more than one Makefile.am having rules to build the same files. Tested that it builds and both `make check` and `make distcheck` work. Tested `make install` and compared the tree with the one installed before this commit, both installed the binaries to the same locations. The binaries are also in the same location in the build tree (for instance, ps/pscommand is still there.) Checked the binaries for the correct libraries linked into them. Binary sizes matched before and after this change. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:28:53 +08:00
pkgconfigdir = $(libdir)/pkgconfig
pkgconfig_DATA = \
library: Rename to libproc-2 What to call the new library? Keep using libprocps wouldn't do, its a very different library from the programs' point of view. It would also mean we could have some clashes around the packages (two package names, same library name). The ancient procps used libproc or libproc-a.b.c where a.b.c was the package version. Kept the revision numbers down (it was always 0.0.0) but the name of the library changed. So if we use libproc-2 is there a clash with an ancient procps? procps v 2.0.0 was around in 1999 so it was 22 years ago, also the name of the library would have been libproc-2.0.0.so not libproc-2.so so we're fine with that. libproc-2 seems to fit, our second major re-work of the procps library. Signed-off-by: Craig Small <csmall@dropbear.xyz>
2021-02-20 19:30:31 +08:00
proc/libproc-2.pc
build-sys: merge automake subdirs into toplevel This will be required for subdir-objects, otherwise automake will have problems with more than one Makefile.am having rules to build the same files. Tested that it builds and both `make check` and `make distcheck` work. Tested `make install` and compared the tree with the one installed before this commit, both installed the binaries to the same locations. The binaries are also in the same location in the build tree (for instance, ps/pscommand is still there.) Checked the binaries for the correct libraries linked into them. Binary sizes matched before and after this change. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:28:53 +08:00
library: Rename to libproc-2 What to call the new library? Keep using libprocps wouldn't do, its a very different library from the programs' point of view. It would also mean we could have some clashes around the packages (two package names, same library name). The ancient procps used libproc or libproc-a.b.c where a.b.c was the package version. Kept the revision numbers down (it was always 0.0.0) but the name of the library changed. So if we use libproc-2 is there a clash with an ancient procps? procps v 2.0.0 was around in 1999 so it was 22 years ago, also the name of the library would have been libproc-2.0.0.so not libproc-2.so so we're fine with that. libproc-2 seems to fit, our second major re-work of the procps library. Signed-off-by: Craig Small <csmall@dropbear.xyz>
2021-02-20 19:30:31 +08:00
EXTRA_DIST += proc/libproc-2.sym
build-sys: merge automake subdirs into toplevel This will be required for subdir-objects, otherwise automake will have problems with more than one Makefile.am having rules to build the same files. Tested that it builds and both `make check` and `make distcheck` work. Tested `make install` and compared the tree with the one installed before this commit, both installed the binaries to the same locations. The binaries are also in the same location in the build tree (for instance, ps/pscommand is still there.) Checked the binaries for the correct libraries linked into them. Binary sizes matched before and after this change. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:28:53 +08:00
# ps/pscommand
ps_pscommand_SOURCES = \
ps/common.h \
ps/display.c \
ps/global.c \
ps/help.c \
ps/output.c \
ps/parser.c \
ps/select.c \
ps/sortformat.c \
ps/stacktrace.c \
library: Remove signal name from library Procps library previously held functions that were about either listing or finding signal names. These are not really the right location for a library about reading procfs. This patch handles signal related functions in two ways: For functions purely found in skill, these have been moved back into this binary as they are used nowhere else. For functions used across the binaries, these have been moved into include/signals.h and lib/signals.c. Besides formatting, these functions are largely the same. To assist the skill functions, two functions to access the signal map array have been added to lib/signals.c
2015-06-29 19:52:51 +08:00
lib/fileutils.c \
lib/signals.c
build-sys: merge automake subdirs into toplevel This will be required for subdir-objects, otherwise automake will have problems with more than one Makefile.am having rules to build the same files. Tested that it builds and both `make check` and `make distcheck` work. Tested `make install` and compared the tree with the one installed before this commit, both installed the binaries to the same locations. The binaries are also in the same location in the build tree (for instance, ps/pscommand is still there.) Checked the binaries for the correct libraries linked into them. Binary sizes matched before and after this change. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:28:53 +08:00
A locale-independent strtod There is a need in some utilities to have a way of accepting both types of decimal points "." and ",". The only way seems to be to rebuild strtod(). This new function will accept "123.456" and "123,456" as 123.456 and considers them the same number. It means we lose thousands separator, but this is rarely used. test scripts are added to check the function returns the proper values. There was simpler predecessor that got stuck on negative 0 or -0.123 which these tests flushed out. References:
2016-03-03 18:24:08 +08:00
build-sys: tweak make & activate some overlooked tests This commit is just preparing for adding an Itemtables verification test by reorganizing stuff and activating a few previously inactive (overlooked?) test programs. Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-15 23:10:10 +08:00
# Test programs required for dejagnu or standalone testing
build-sys: Build check programs only on make check noinst_PROGRAMS are built with "make" even though we had the test programs in there and only needed them for "make check". In theory the check target should depend on check_PROGRAMS as check-am target does and the document states it should, but for reasons understood by the automake whisperers only, it doesn't build them. check only depends on BUILT_SOURCES for some reason. check-am: all-am $(MAKE) $(AM_MAKEFLAGS) $(check_PROGRAMS) $(MAKE) $(AM_MAKEFLAGS) check-TESTS check: $(BUILT_SOURCES) $(MAKE) $(AM_MAKEFLAGS) check-recursive References: https://www.gnu.org/software/automake/manual/html_node/Scripts_002dbased-Testsuites.html
2020-10-19 17:05:41 +08:00
check_PROGRAMS = \
Create test process For the test suite, procps used to use sleep which would just create a process or two to test the tools against. Some setups coreutils creates all programs including sleep into one blob which means a lot of the tests fail, see issue #2 procps has its own sleep program now.
2015-06-13 13:04:31 +08:00
lib/test_strutils \
lib/test_fileutils \
build-sys: tweak make & activate some overlooked tests This commit is just preparing for adding an Itemtables verification test by reorganizing stuff and activating a few previously inactive (overlooked?) test programs. Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-15 23:10:10 +08:00
lib/test_process \
lib/test_strtod_nol
build-sys: merge automake subdirs into toplevel This will be required for subdir-objects, otherwise automake will have problems with more than one Makefile.am having rules to build the same files. Tested that it builds and both `make check` and `make distcheck` work. Tested `make install` and compared the tree with the one installed before this commit, both installed the binaries to the same locations. The binaries are also in the same location in the build tree (for instance, ps/pscommand is still there.) Checked the binaries for the correct libraries linked into them. Binary sizes matched before and after this change. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:28:53 +08:00
lib_test_strutils_SOURCES = lib/test_strutils.c lib/strutils.c
Added Cygwin build support strverscmp is included to satisfy a dependency in Cygwin. Excluded utmp and prctl functions that are not supported currently.
2016-03-11 07:04:27 +08:00
lib_test_strutils_LDADD = $(CYGWINFLAGS)
build-sys: merge automake subdirs into toplevel This will be required for subdir-objects, otherwise automake will have problems with more than one Makefile.am having rules to build the same files. Tested that it builds and both `make check` and `make distcheck` work. Tested `make install` and compared the tree with the one installed before this commit, both installed the binaries to the same locations. The binaries are also in the same location in the build tree (for instance, ps/pscommand is still there.) Checked the binaries for the correct libraries linked into them. Binary sizes matched before and after this change. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:28:53 +08:00
lib_test_fileutils_SOURCES = lib/test_fileutils.c lib/fileutils.c
Added Cygwin build support strverscmp is included to satisfy a dependency in Cygwin. Excluded utmp and prctl functions that are not supported currently.
2016-03-11 07:04:27 +08:00
lib_test_fileutils_LDADD = $(CYGWINFLAGS)
Do not link test process to libprocps The test process introduced at 420cd9c7 incorrectly linked to libprocps which made the CI runner fail.
2015-06-14 06:54:59 +08:00
lib_test_process_SOURCES = lib/test_process.c
Added Cygwin build support strverscmp is included to satisfy a dependency in Cygwin. Excluded utmp and prctl functions that are not supported currently.
2016-03-11 07:04:27 +08:00
lib_test_process_LDADD = $(CYGWINFLAGS)
build-sys: tweak make & activate some overlooked tests This commit is just preparing for adding an Itemtables verification test by reorganizing stuff and activating a few previously inactive (overlooked?) test programs. Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-15 23:10:10 +08:00
lib_test_strtod_nol_SOURCES = lib/test_strtod_nol.c lib/strutils.c
lib_test_strtod_nol_LDADD = $(CYGWINFLAGS)
build-sys: Build check programs only on make check noinst_PROGRAMS are built with "make" even though we had the test programs in there and only needed them for "make check". In theory the check target should depend on check_PROGRAMS as check-am target does and the document states it should, but for reasons understood by the automake whisperers only, it doesn't build them. check only depends on BUILT_SOURCES for some reason. check-am: all-am $(MAKE) $(AM_MAKEFLAGS) $(check_PROGRAMS) $(MAKE) $(AM_MAKEFLAGS) check-TESTS check: $(BUILT_SOURCES) $(MAKE) $(AM_MAKEFLAGS) check-recursive References: https://www.gnu.org/software/automake/manual/html_node/Scripts_002dbased-Testsuites.html
2020-10-19 17:05:41 +08:00
check_PROGRAMS += \
build-sys: added a 'test_Itemtables' to testing scheme This change sets the stage for exploiting the recently added ITEMTABLE_DEBUG #define. All tests are performed in a single module (after trying 6 separate programs). The chances of each test detecting errors is extremely remote (at least while I'm maintaining these modules). However, this single program approach has one flaw and it relates to the response whenever an error is found. Each of those six new API modules calls Exit() if they detect an error. Otherwise, incorrect results would be produced at the least or an abend encountered at most. This means that multiple 'make check' invocations will be needed if more than 1 module actually was in error. All in all, it is a small price for a large assurance. Reference(s): https://www.freelists.org/post/procps/keep-on-patchin,7 Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-16 01:12:12 +08:00
proc/test_Itemtables \
build-sys: tweak make & activate some overlooked tests This commit is just preparing for adding an Itemtables verification test by reorganizing stuff and activating a few previously inactive (overlooked?) test programs. Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-15 23:10:10 +08:00
proc/test_pids \
proc/test_uptime \
proc/test_sysinfo \
proc/test_version \
proc/test_namespace
build-sys: merge automake subdirs into toplevel This will be required for subdir-objects, otherwise automake will have problems with more than one Makefile.am having rules to build the same files. Tested that it builds and both `make check` and `make distcheck` work. Tested `make install` and compared the tree with the one installed before this commit, both installed the binaries to the same locations. The binaries are also in the same location in the build tree (for instance, ps/pscommand is still there.) Checked the binaries for the correct libraries linked into them. Binary sizes matched before and after this change. Signed-off-by: Filipe Brandenburger <filbranden@google.com>
2015-05-02 12:28:53 +08:00
build-sys: added a 'test_Itemtables' to testing scheme This change sets the stage for exploiting the recently added ITEMTABLE_DEBUG #define. All tests are performed in a single module (after trying 6 separate programs). The chances of each test detecting errors is extremely remote (at least while I'm maintaining these modules). However, this single program approach has one flaw and it relates to the response whenever an error is found. Each of those six new API modules calls Exit() if they detect an error. Otherwise, incorrect results would be produced at the least or an abend encountered at most. This means that multiple 'make check' invocations will be needed if more than 1 module actually was in error. All in all, it is a small price for a large assurance. Reference(s): https://www.freelists.org/post/procps/keep-on-patchin,7 Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-16 01:12:12 +08:00
proc_test_Itemtables_SOURCES = proc/test_Itemtables.c
library: Rename to libproc-2 What to call the new library? Keep using libprocps wouldn't do, its a very different library from the programs' point of view. It would also mean we could have some clashes around the packages (two package names, same library name). The ancient procps used libproc or libproc-a.b.c where a.b.c was the package version. Kept the revision numbers down (it was always 0.0.0) but the name of the library changed. So if we use libproc-2 is there a clash with an ancient procps? procps v 2.0.0 was around in 1999 so it was 22 years ago, also the name of the library would have been libproc-2.0.0.so not libproc-2.so so we're fine with that. libproc-2 seems to fit, our second major re-work of the procps library. Signed-off-by: Craig Small <csmall@dropbear.xyz>
2021-02-20 19:30:31 +08:00
proc_test_Itemtables_LDADD = proc/libproc-2.la
tests: update template and add pids Generalised the library API tests and created a common test-runner. Instead of copy and pasting the same code in each time. First cut of pids API test, for _new so far.
2016-04-19 19:33:02 +08:00
proc_test_pids_SOURCES = proc/test_pids.c
library: Rename to libproc-2 What to call the new library? Keep using libprocps wouldn't do, its a very different library from the programs' point of view. It would also mean we could have some clashes around the packages (two package names, same library name). The ancient procps used libproc or libproc-a.b.c where a.b.c was the package version. Kept the revision numbers down (it was always 0.0.0) but the name of the library changed. So if we use libproc-2 is there a clash with an ancient procps? procps v 2.0.0 was around in 1999 so it was 22 years ago, also the name of the library would have been libproc-2.0.0.so not libproc-2.so so we're fine with that. libproc-2 seems to fit, our second major re-work of the procps library. Signed-off-by: Craig Small <csmall@dropbear.xyz>
2021-02-20 19:30:31 +08:00
proc_test_pids_LDADD = proc/libproc-2.la
build-sys: tweak make & activate some overlooked tests This commit is just preparing for adding an Itemtables verification test by reorganizing stuff and activating a few previously inactive (overlooked?) test programs. Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-15 23:10:10 +08:00
proc_test_uptime_SOURCES = proc/test_uptime.c
library: Rename to libproc-2 What to call the new library? Keep using libprocps wouldn't do, its a very different library from the programs' point of view. It would also mean we could have some clashes around the packages (two package names, same library name). The ancient procps used libproc or libproc-a.b.c where a.b.c was the package version. Kept the revision numbers down (it was always 0.0.0) but the name of the library changed. So if we use libproc-2 is there a clash with an ancient procps? procps v 2.0.0 was around in 1999 so it was 22 years ago, also the name of the library would have been libproc-2.0.0.so not libproc-2.so so we're fine with that. libproc-2 seems to fit, our second major re-work of the procps library. Signed-off-by: Craig Small <csmall@dropbear.xyz>
2021-02-20 19:30:31 +08:00
proc_test_uptime_LDADD = proc/libproc-2.la
build-sys: tweak make & activate some overlooked tests This commit is just preparing for adding an Itemtables verification test by reorganizing stuff and activating a few previously inactive (overlooked?) test programs. Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-15 23:10:10 +08:00
proc_test_sysinfo_SOURCES = proc/test_sysinfo.c
library: Rename to libproc-2 What to call the new library? Keep using libprocps wouldn't do, its a very different library from the programs' point of view. It would also mean we could have some clashes around the packages (two package names, same library name). The ancient procps used libproc or libproc-a.b.c where a.b.c was the package version. Kept the revision numbers down (it was always 0.0.0) but the name of the library changed. So if we use libproc-2 is there a clash with an ancient procps? procps v 2.0.0 was around in 1999 so it was 22 years ago, also the name of the library would have been libproc-2.0.0.so not libproc-2.so so we're fine with that. libproc-2 seems to fit, our second major re-work of the procps library. Signed-off-by: Craig Small <csmall@dropbear.xyz>
2021-02-20 19:30:31 +08:00
proc_test_sysinfo_LDADD = proc/libproc-2.la
build-sys: tweak make & activate some overlooked tests This commit is just preparing for adding an Itemtables verification test by reorganizing stuff and activating a few previously inactive (overlooked?) test programs. Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-15 23:10:10 +08:00
proc_test_version_SOURCES = proc/test_version.c
library: Rename to libproc-2 What to call the new library? Keep using libprocps wouldn't do, its a very different library from the programs' point of view. It would also mean we could have some clashes around the packages (two package names, same library name). The ancient procps used libproc or libproc-a.b.c where a.b.c was the package version. Kept the revision numbers down (it was always 0.0.0) but the name of the library changed. So if we use libproc-2 is there a clash with an ancient procps? procps v 2.0.0 was around in 1999 so it was 22 years ago, also the name of the library would have been libproc-2.0.0.so not libproc-2.so so we're fine with that. libproc-2 seems to fit, our second major re-work of the procps library. Signed-off-by: Craig Small <csmall@dropbear.xyz>
2021-02-20 19:30:31 +08:00
proc_test_version_LDADD = proc/libproc-2.la
build-sys: tweak make & activate some overlooked tests This commit is just preparing for adding an Itemtables verification test by reorganizing stuff and activating a few previously inactive (overlooked?) test programs. Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-15 23:10:10 +08:00
proc_test_namespace_SOURCES = proc/test_namespace.c
library: Rename to libproc-2 What to call the new library? Keep using libprocps wouldn't do, its a very different library from the programs' point of view. It would also mean we could have some clashes around the packages (two package names, same library name). The ancient procps used libproc or libproc-a.b.c where a.b.c was the package version. Kept the revision numbers down (it was always 0.0.0) but the name of the library changed. So if we use libproc-2 is there a clash with an ancient procps? procps v 2.0.0 was around in 1999 so it was 22 years ago, also the name of the library would have been libproc-2.0.0.so not libproc-2.so so we're fine with that. libproc-2 seems to fit, our second major re-work of the procps library. Signed-off-by: Craig Small <csmall@dropbear.xyz>
2021-02-20 19:30:31 +08:00
proc_test_namespace_LDADD = proc/libproc-2.la
A locale-independent strtod There is a need in some utilities to have a way of accepting both types of decimal points "." and ",". The only way seems to be to rebuild strtod(). This new function will accept "123.456" and "123,456" as 123.456 and considers them the same number. It means we lose thousands separator, but this is rarely used. test scripts are added to check the function returns the proper values. There was simpler predecessor that got stuck on negative 0 or -0.123 which these tests flushed out. References:
2016-03-03 18:24:08 +08:00
Port of merge request 49 to newlib Wayne Porter made !49 which added Cygwin support to the master branch This is the port of those changes to newlib
2017-08-19 21:05:22 +08:00
if CYGWIN
skill_LDADD = $(CYGWINFLAGS)
kill_LDADD = $(CYGWINFLAGS)
free_LDADD = $(CYGWINFLAGS)
pgrep_LDADD = $(CYGWINFLAGS)
pkill_LDADD = $(CYGWINFLAGS)
pidof_LDADD = $(CYGWINFLAGS)
pmap_LDADD = $(CYGWINFLAGS)
snice_LDADD = $(CYGWINFLAGS)
tload_LDADD = $(CYGWINFLAGS)
uptime_LDADD = $(CYGWINFLAGS)
w_LDADD = $(CYGWINFLAGS)
vmstat_LDADD = $(CYGWINFLAGS)
endif
build-sys: allow packagers to choose what is installed Distribution maintainers may not want to use upstream example files in their procps-ng package. Reference: http://permalink.gmane.org/gmane.linux.arch.devel/17440 Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2012-04-29 23:22:29 +08:00
if EXAMPLE_FILES
Port of merge request 49 to newlib Wayne Porter made !49 which added Cygwin support to the master branch This is the port of those changes to newlib
2017-08-19 21:05:22 +08:00
if !CYGWIN
build-sys: take autotools in use again This will revert change at Oct 2002 when autotools support was removed. Unlike before the package developers are expected to use ./autogen.sh to generate ./configure script, and run make after that. The build system is also able to create, with make dist, a tar ball release which compiles correctly, and has files which seemed to be important to have. The patch removes few unnecessary files, but no everything. Files procps.lsm and procps.spec in git repository are useless as is, but I left them lying around for someone who can make more justified call about removal of them. Last, but not least package version number is set 3.3.0 to distinct this procps from the sourceforge's upstream procps. Please notice that libproc relese is kept as 3.2.8. Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2011-06-04 22:26:58 +08:00
sysconf_DATA = sysctl.conf
build-sys: allow packagers to choose what is installed Distribution maintainers may not want to use upstream example files in their procps-ng package. Reference: http://permalink.gmane.org/gmane.linux.arch.devel/17440 Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2012-04-29 23:22:29 +08:00
endif
Port of merge request 49 to newlib Wayne Porter made !49 which added Cygwin support to the master branch This is the port of those changes to newlib
2017-08-19 21:05:22 +08:00
endif
build-sys: take autotools in use again This will revert change at Oct 2002 when autotools support was removed. Unlike before the package developers are expected to use ./autogen.sh to generate ./configure script, and run make after that. The build system is also able to create, with make dist, a tar ball release which compiles correctly, and has files which seemed to be important to have. The patch removes few unnecessary files, but no everything. Files procps.lsm and procps.spec in git repository are useless as is, but I left them lying around for someone who can make more justified call about removal of them. Last, but not least package version number is set 3.3.0 to distinct this procps from the sourceforge's upstream procps. Please notice that libproc relese is kept as 3.2.8. Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2011-06-04 22:26:58 +08:00
build-sys: earlier patch broke the build The commit 47cc1b6ccfd1e6e10aafbf21e932991a10c97f7e might have fixed an issue when distribution is built, but it broke make after running ./configure which this commit fixes. Reference: http://www.delorie.com/gnu/docs/automake/automake_66.html Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2012-06-24 18:51:18 +08:00
BUILT_SOURCES = $(top_srcdir)/.version
Fix some man-po stuff for distcheck distcheck failed because the man-po scripts weren't sourcing or escaping the directories correctly. This is a partial fix, but at least distcheck is happy.
2014-06-24 20:20:13 +08:00
build-sys: Add check-lib target The referenced commits created the library infrastructure and test program to validate that the structures and macros line up with each other. The library needs to be (re)built with -DITEMTABLE_DEBUG and then the test program ran. We clean before and after so we are not testing a non-debug library or having a debug library hanging around to cause future problems. Due to test_Itemtables depending on the library, we don't need to explicitly build the library. To validate the library structure/header corrospondence run: make check-lib References: commit e616409aa497b5dc656dc7a5bd0a21adf0ee4d36 commit 92d0297e1e4d5946c5b098e37c91c7e524a0eca0 https://www.freelists.org/post/procps/keep-on-patchin,19
2020-10-19 16:25:33 +08:00
check-lib: clean
$(MAKE) CFLAGS=-DITEMTABLE_DEBUG proc/test_Itemtables
$(top_builddir)/proc/test_Itemtables
build-sys: a small tweak to the new 'check-lib' target So as to not obscure the results from this new target, we'll redirect that final 'make clean' output to null. Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-10-21 13:00:00 +08:00
$(MAKE) clean &>/dev/null
build-sys: Add check-lib target The referenced commits created the library infrastructure and test program to validate that the structures and macros line up with each other. The library needs to be (re)built with -DITEMTABLE_DEBUG and then the test program ran. We clean before and after so we are not testing a non-debug library or having a debug library hanging around to cause future problems. Due to test_Itemtables depending on the library, we don't need to explicitly build the library. To validate the library structure/header corrospondence run: make check-lib References: commit e616409aa497b5dc656dc7a5bd0a21adf0ee4d36 commit 92d0297e1e4d5946c5b098e37c91c7e524a0eca0 https://www.freelists.org/post/procps/keep-on-patchin,19
2020-10-19 16:25:33 +08:00
build-sys: cleanup of tests Removed dependencies on test_nsutils as they are not used in newlib. Had two TESTS lines due to master merge, now only one.
2016-07-09 13:06:32 +08:00
# Test programs not used by dejagnu but run directly
build-sys: tweak make & activate some overlooked tests This commit is just preparing for adding an Itemtables verification test by reorganizing stuff and activating a few previously inactive (overlooked?) test programs. Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-15 23:10:10 +08:00
TESTS = \
tests: update template and add pids Generalised the library API tests and created a common test-runner. Instead of copy and pasting the same code in each time. First cut of pids API test, for _new so far.
2016-04-19 19:33:02 +08:00
proc/test_pids \
library: document and tests for uptime functions man pages for the three procps_uptime* functions and simple test scripts for same functions.
2016-04-16 20:02:10 +08:00
proc/test_uptime \
build-sys: tweak make & activate some overlooked tests This commit is just preparing for adding an Itemtables verification test by reorganizing stuff and activating a few previously inactive (overlooked?) test programs. Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-15 23:10:10 +08:00
proc/test_sysinfo \
libprocps version test and documentation test binary and man page for the version part of libprocps. It's a simple start, but it's a start!
2016-04-14 20:28:38 +08:00
proc/test_version \
build-sys: tweak make & activate some overlooked tests This commit is just preparing for adding an Itemtables verification test by reorganizing stuff and activating a few previously inactive (overlooked?) test programs. Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-15 23:10:10 +08:00
proc/test_namespace \
lib/test_fileutils \
set test programs to check_PROGRAMS Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2016-03-08 04:19:47 +08:00
lib/test_strtod_nol
build-sys: tweak make & activate some overlooked tests This commit is just preparing for adding an Itemtables verification test by reorganizing stuff and activating a few previously inactive (overlooked?) test programs. Signed-off-by: Jim Warner <james.warner@comcast.net>
2020-08-15 23:10:10 +08:00
build-sys: Build check programs only on make check noinst_PROGRAMS are built with "make" even though we had the test programs in there and only needed them for "make check". In theory the check target should depend on check_PROGRAMS as check-am target does and the document states it should, but for reasons understood by the automake whisperers only, it doesn't build them. check only depends on BUILT_SOURCES for some reason. check-am: all-am $(MAKE) $(AM_MAKEFLAGS) $(check_PROGRAMS) $(MAKE) $(AM_MAKEFLAGS) check-TESTS check: $(BUILT_SOURCES) $(MAKE) $(AM_MAKEFLAGS) check-recursive References: https://www.gnu.org/software/automake/manual/html_node/Scripts_002dbased-Testsuites.html
2020-10-19 17:05:41 +08:00
# Automake should do this, but it doesn't
build-sys: check depends on programs For some unknown reason, make check doesn't depend on either the check programs or the actual programs under test. This means if you try to run make check right off the bat from a clean git repositorty, it will fail as it won't be able to run the unbuilt binaries.
2022-03-21 18:37:17 +08:00
check: $(check_PROGRAMS) $(PROGRAMS)
library: tests for sysinfo First set of tests for the library API, this lot checks the two functions out of sysinfo.c Signed-off-by: Craig Small <csmall@enc.com.au>
2015-07-20 20:23:21 +08:00
Makefile.am fixes Two problems. 1) skill/snice : distribution doesnt mean install If you don't set your configure flags right, you dont install the skill/snice man pages which means you will break any subsequent compiles with the flags enabled. Man pages not to be installed should still be distributed. 2) The git version into Makefile.am breaks under certain conditions. The easy break for this is: touch aclocal.m4 make We need this script added plus some dist hook magic that got left out.
2012-05-20 15:27:14 +08:00
$(top_srcdir)/.version:
build-sys: earlier patch broke the build The commit 47cc1b6ccfd1e6e10aafbf21e932991a10c97f7e might have fixed an issue when distribution is built, but it broke make after running ./configure which this commit fixes. Reference: http://www.delorie.com/gnu/docs/automake/automake_66.html Signed-off-by: Sami Kerola <kerolasa@iki.fi>
2012-06-24 18:51:18 +08:00
touch $(top_srcdir)/.version
Makefile.am fixes Two problems. 1) skill/snice : distribution doesnt mean install If you don't set your configure flags right, you dont install the skill/snice man pages which means you will break any subsequent compiles with the flags enabled. Man pages not to be installed should still be distributed. 2) The git version into Makefile.am breaks under certain conditions. The easy break for this is: touch aclocal.m4 make We need this script added plus some dist hook magic that got left out.
2012-05-20 15:27:14 +08:00
echo $(VERSION) > $@-t && mv $@-t $@
dist-hook:
echo $(VERSION) > $(distdir)/.tarball-version
Moved man-po pot file creation into Makefile The pot files for man-po are part of the extra_dist target so are built at dist time. These used to be created as part of the dist-hook. However it is better to control their builds in the Makefile so they are conditionally built. It also means distcheck doesn't complain when they are added to the CLEANFILES.
2014-06-25 21:11:15 +08:00
Added get-trans target to Makefile The get-trans target rsyncs the latest copies of translation files from the translation project. I put this target in because I always forget the exact syntax of the command. Signed-off-by: Craig Small <csmall@enc.com.au>
2014-02-22 08:34:53 +08:00
get-trans:
Translated man page scripts Mario sent some scripts to maintain translated man pages. This commit is almost the same scripts with minor adjustments. Reference: http://www.freelists.org/post/procps/Translations-for-man-pages,17
2014-05-28 17:51:37 +08:00
echo "Getting the latest translations from translationproject.org..."
fix url for rsync Signed-off-by: Trần Ngọc Quân <vnwildman@gmail.com>
2014-04-17 15:12:01 +08:00
rsync -Lrtvz translationproject.org::tp/latest/procps-ng/ po
Translated man page scripts Mario sent some scripts to maintain translated man pages. This commit is almost the same scripts with minor adjustments. Reference: http://www.freelists.org/post/procps/Translations-for-man-pages,17
2014-05-28 17:51:37 +08:00
rsync -Lrtvz translationproject.org::tp/latest/procps-ng-man/ man-po
Reference in New Issue Copy Permalink