The functional tests and util tests both require a config file that is
generated by ./configure. This commit merges those two config
files into a single configuration file that can be shared by both tests.
The config from config.ini is put into a Namespace object to maintain
the interface with bctest.py. A future commit could change this
interface to use a dictionary instead of a namespace.
d80e3cb Support gathering of code coverage data for RPC tests (dexX7)
e3b5e6c Run extended BitcoinJ tests for coverage based on config (dexX7)
45d4ff0 Add config option to enable extended RPC tests for code coverage (dexX7)
8e3a27b Require Python for RPC tests, when using lcov (dexX7)
d425877 Remove coverage and test related files, when cleaning up (dexX7)
4d2a926 Ignore coverage data related and temporary test files (dexX7)
No need to waste startup time building something that can be done
at compile time.
This also resolves a clang++ warning originally reported in #4714,
univalue/univalue_write.cpp:33:12: warning: array subscript is of type 'char
escapes['"'] = "\\"";
^~~~
etc.
This is a simple utility that provides command line manipulation of
a hex-encoded TX. The utility takes a hex string on the command line
as input, performs zero or more mutations, and outputs a hex string
to standard output.
This utility is also an intentional exercise of the "bitcoin library"
concept. It is designed to require minimal libraries, and works
entirely without need for any RPC or P2P communication.
See "bitcoin-tx --help" for command and options summary.
Prior to this change, `git status` would report untracked files of the
following sort if run during a build:
?? src/rpcprotocol.o-e628def3
These files should be explicitly ignored not only because they are a
nuisance, but given that they appear and disappear quickly, they may be
inadvertently added to the index even if one has been careful to check
for untracked files with `git status` prior to a `git add .`.
This adds an executable `bitcoin-rpc` that only serves as a Bitcoin RPC
client.
The commit does not remove RPC functionality from the `bitcoind` yet,
this functionality should be deprecated but is left for a later version
to give users some time to switch.
This change moves test data into the binaries rather than reading them from
the disk at runtime.
Advantages:
- Tests become distributable
- Cross-compile friendly. Build on one machine and execute in an arbitrary
location on another.
- Easier testing for backports. Users can verify that tests pass without having
to track down corresponding test data.
- More trustworthy test results and easier quality assurance as tests make
fewer assumptions about their environment.
- Tests could theoretically run at client/daemon startup and exit on failure.
Disadvantages:
- Required 'hexdump' build-dependency. This is a standard bsd tool that should
be usable everywhere. It is likely already installed on all build-machines.
- Tests can no longer be fudged after build by altering test-data.
All client version information is moved to version.cpp, which optionally
(-DHAVE_BUILD_INFO) includes build.h. build.h is automatically generated
on supporting platforms via contrib/genbuild.sh, using git describe.
The git export-subst attribute is used to put the commit id statically
in version.cpp inside generated archives, and this value is used if no
build.h is present.
The gitian descriptors are modified to use git archive instead of a
copy, to create the src/ directory in the output. This way,
src/src/version.cpp will contain the static commit id. To prevent
gitian builds from getting the "-dirty" marker in their git-describe
generated identifiers, no touching of files or running sed on the
makefile is performed anymore. This does not seem to influence
determinism.
there is no internal modification of any file in this commit
files are moved into directories according to established standards in
sourcecode distribution; these directories contain:
src - Files that are used in constructing the executable binaries,
but are not installed.
doc - Files in HTML and text format that document usage, quirks of
the implementation, and contributor checklists.
locale - Files that contain human language translation of strings
used in the program
contrib - Files contributed from distributions or other third party
implementing scripts and auxiliary programs
Sjors Provoost