Age | Commit message (Collapse) | Author |
|
Disabling warnings can be tricky, because doing so can cause a different
compiler to create new warnings about unsupported disable flags. Also, some
warnings don't surface until they're paired with another warning (gcc). For
example, adding "-Wno-foo" won't cause any trouble, but if there's a legitimate
warning emitted, the "unknown option -Wno-foo" will show up as well.
Work around this in 2 ways:
1. When checking to see if -Wno-foo is supported, check for "-Wfoo" instead.
2. Enable -Werror while checking 1.
If "-Werror -Wfoo" compiles, "-Wno-foo" is almost guaranteed to be supported.
-Werror itself is also checked. If that fails to compile by itself, it likely
means that the user added a flag that adds a warning. In that case, -Werror
won't be used while checking, and the build may be extra noisy. The user would
need to fix the bad input flag.
Also, silence 2 more additional warnings that can show up post-c++11.
|
|
|
|
leveldb's buildsystem causes us a few problems:
- breaks out-of-tree builds
- forces flags used for some tools
- limits cross builds
Rather than continuing to add wrappers around it, simply integrate it into our
build.
|
|
Unfortunately, the target namees defined at the Makefile.am level can't be used
for *.in substitution. So these new defines will have to stay synced up with
those targets.
Using the new variables for the deploy targets in the main Makefile.am will
ensure that they stay in sync, otherwise build tests will fail.
|
|
This removes the following executables from the binary gitian release:
- test_bitcoin-qt[.exe]
- bench_bitcoin[.exe]
@jonasschnelli and me discussed this on IRC a few days ago - unlike the
normal `bitcoin_tests` which is useful to see if it is safe to run
bitcoin on a certain OS/environment combination, there is no good reason
to include these. Better to leave them out to reduce the download
size.
Sizes from the 0.12 release:
```
2.4M bitcoin-0.12.0/bin/bench_bitcoin.exe
22M bitcoin-0.12.0/bin/test_bitcoin-qt.exe
```
|
|
72fd008 Fix quoting of copyright holders in configure.ac. (Daniel Kraft)
|
|
Ubuntu 16.04 "xenial xerus" does not come with Python 2.x by default.
It is possible to install a python-2.7 package, but this has its own
problem: no `python` or `python2` symlink (see #7717).
This fixes the following scripts to work with python 3:
- `make check` (bctest,py, bitcoin-util-test.py)
- `make translate` (extract_strings_qt.py)
- `make symbols-check` (symbol-check.py)
- `make security-check` (security-check.py)
Explicitly call the python commands using $(PYTHON) instead
of relying on the interpreter line at the top of the scripts.
|
|
The old configure.ac did not work for a copyright holders string
containing commas due to insufficient quoting. The new one allows this.
While this is, of course, not of direct consequence to the current code
(where the string is "Bitcoin Core"), it should still be fixed now that
the string is actually factored out.
|
|
42407ed build-unix: Update UniValue build conditions (Luke Dashjr)
cdcad9f LDADD dependency order shuffling (Luke Dashjr)
62f7f2e Bugfix: Always include univalue in DIST_SUBDIRS (Luke Dashjr)
2356515 Change default configure option --with-system-univalue to "no" (Luke Dashjr)
5d3b29b doc: Add UniValue to build instructions (Luke Dashjr)
ab22705 Build against system UniValue when available (Luke Dashjr)
2adf7e2 Bugfix: The var is LIBUNIVALUE,not LIBBITCOIN_UNIVALUE (Luke Dashjr)
|
|
|
|
|
|
it gets passed to extract-strings correctly
|
|
|
|
glibc absorbed clock_gettime in 2.17. librt (its previous location) is safe to
link in anyway for back-compat.
Fixes #7420
|
|
These are not added to the default checks because some of them depend on
release-build configs.
|
|
|
|
bd34174 Update license year range to 2016 (Prayag Verma)
|
|
|
|
|
|
Due to include ordering, defining in one place was not enough to ensure correct
usage. Use global defines so that we don't have to worry abou this ordering.
Also add a comment in configure about the test.
|
|
This is ugly, but temporary. boost::filesystem will likely be dropped soon
after c++11 is enabled. Otherwise, we could simply roll our own copy_file. I've
fixed this at the buildsystem level for now in order to avoid mixing in
functional changes.
Explanation:
If boost (prior to 1.57) was built without c++11, it emulated scoped enums
using c++98 constructs. Unfortunately, this implementation detail leaked into
the abi. This was fixed in 1.57.
When building against that installed version using c++11, the headers pick up
on the native c++11 scoped enum support and enable it, however it will fail to
link. This can be worked around by disabling c++11 scoped enums if linking will
fail.
Add an autoconf test to determine incompatibility. At build-time, if native
enums are being used (a c++11 build), and force-disabling them causes a
successful link, we can be sure that there's an incompatibility and enable the
work-around.
|
|
This helps avoid accidental removal of upstream copyright names
|
|
|
|
|
|
|
|
... in preparation for 0.13
|
|
|
|
This allows for fPIE to be used selectively.
|
|
If both Qt4 and Qt5 development headers are installed, use Qt5. Building
against Qt5 should be encouraged as that is where active development
happens.
|
|
040c0ea Init: Cleanup error and warning strings (MarcoFalke)
6782f58 [trivial] Latest config.guess (MarcoFalke)
bf68191 [trivial] rpcnet: fix typo (MarcoFalke)
95f4291 [trivial] Rewrite help text for feature enabled by default (MarcoFalke)
|
|
When using lcov to gather code coverage data, the configuration option
`--enable-extended-rpc-tests` may be used to enable extended RPC tests.
|
|
Because Python is (going to be) used to run the RPC tests, when
gathering coverage data with lcov, it is explicitly checked, whether
Python is really available.
|
|
c.f #6748
|
|
7072c54 Support very-fast-running benchmarks (Gavin Andresen)
535ed92 Simple benchmarking framework (Gavin Andresen)
|
|
dd28089 autotools: move checking for zmq library to common area in configure.ac (Johnathan Corgan)
|
|
bb24835 build: disable -Wself-assign (Wladimir J. van der Laan)
|
|
9ee5ac8 Rewrite help texts for features enabled by default. (Pavel Janík)
|
|
Don't chmod a repository-included file in the configure script, and
`tests_config.py` is a module that doesn't need to be executable.
|
|
* Fixes #6679
* Tested with --disable-zmq
* Tested with and without pkgconfig
* Tested with and without zmq installed
Signed-off-by: Johnathan Corgan <johnathan@corganlabs.com>
|
|
|
|
5467820 Migrated rpc-tests.sh to all python rpc-tests.py (ptschip)
|
|
96106f0 [Trivial] start the help texts with lowercase (paveljanik)
|
|
1) created rpc-tests.py
2) deleted rpc-tests.sh
3) travis.yml points to rpc-tests.py
4) Modified Makefile.am
5) Updated README.md
6) Added tests_config.py and deleted tests-config.sh
7) Modified configure.ac with script to set correct path in tests_config.py
|
|
Prevent these warnings in clang 3.6:
./serialize.h:96:9: warning: explicitly assigning value of variable of type 'uint64_t' (aka 'unsigned long') to itself [-Wself-assign]
obj = (obj);
~~~ ^ ~~~
|
|
a3874c7 doc: no longer require use of openssl in OpenBSD build guide (Wladimir J. van der Laan)
5978388 build: remove libressl check (Wladimir J. van der Laan)
|
|
Now that BIP66 passed, OpenSSL is no longer directly part of the
consensus. What matters is that DER signatures are correctly parsed, and
secp256k1 crypto is implemented correctly (as well as the other
functions we use from OpenSSL, such as random number generation)
This means that effectively, using LibreSSL is not a larger risk than
using another version of OpenSSL.
Remove the specific check for LibreSSL.
Includes the still-relevant part of #6729: make sure CHECK_HEADER is
called using the right CXXFLAGS, not CFLAGS (as AC_LANG is c++).
|
|
similar to secp256k1 include and compile univalue over a subtree
|
|
Benchmarking framework, loosely based on google's micro-benchmarking
library (https://github.com/google/benchmark)
Wny not use the Google Benchmark framework? Because adding Even More Dependencies
isn't worth it. If we get a dozen or three benchmarks and need nanosecond-accurate
timings of threaded code then switching to the full-blown Google Benchmark library
should be considered.
The benchmark framework is hard-coded to run each benchmark for one wall-clock second,
and then spits out .csv-format timing information to stdout. It is left as an
exercise for later (or maybe never) to add command-line arguments to specify which
benchmark(s) to run, how long to run them for, how to format results, etc etc etc.
Again, see the Google Benchmark framework for where that might end up.
See src/bench/MilliSleep.cpp for a sanity-test benchmark that just benchmarks
'sleep 100 milliseconds.'
To compile and run benchmarks:
cd src; make bench
Sample output:
Benchmark,count,min,max,average
Sleep100ms,10,0.101854,0.105059,0.103881
|
|
|
|
Signed-off-by: Johnathan Corgan <johnathan@corganlabs.com>
|