Using the newer po4a tool for manpage translations. Also removing
the manpage po file update from dist target because it should be
something the is explicitly done.
The git repository will hold the original man pages and the
po translation files. The distribution tarball will hold those
and the translated manpages. This means most people won't need po4a
as the distribution fill will have these translated manpages.
The combined results of merge request #49 without that
overhead plus distortion in this repository's history.
Prototyped-by: Wayne Porter <wporter82@gmail.com>
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:
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>
The two extra extended pmap options were not tested previously.
We test against our known process and process 1 which we should
not be able to get data for.
Unfortunately, the tests cannot catch SEGSEGVs but they should.
Signed-off-by: Craig Small <csmall@enc.com.au>
Even as conservative project as coreutils has switched to xz distributions so
neither should we have any reason to use gz and waste space & bandwidth.
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
The library used to be called libprocps but it was renamed to make sure
there was only one. However the formatting of the library SONAME has
changed so there cannot be any confusion.
libprocps makes it clear that its a library from this project and not a
set of functions directly on the filesystem.
Previously the version of libproc always tracked the version of procps.
This doesn't work when other non-procps programs link to the library as
they are always playing catch up.
This change makes the library version independent of the procps version.
It will only be incremented when needed.
procps works well on Linux, on other arches there are some strange
differences due to their emulation of procfs which is not 100%
Disabling checks for non-linux until that can be sorted out.
The library file version string is taken from configure.ac AC_INIT.
Reference: http://www.freelists.org/archive/procps/09-2011
Signed-off-by: Jim Warner <james.warner@comcast.net>
Signed-off-by: Craig Small <csmall-procps@enc.com.au>
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
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>
