32-bit build would fail to link with 'mdb_env_create undefined' (because
for 32-bit build, mdb_env_create_vl32 is defined instead).
This bug was introduced with the recent change to virtual object
libraries. The problem is that the COMPILE_DEFINITIONS property
was not propagated from dependee target (lmdb) to depedent
target's (blockchain_db) virtual object lib (obj_blockchain_db).
This patch makes that happen.
I chose to include INTERFACE_COMPILE_DEFINITIONS because there
should not be a need to propagate private defs, but it doesn't
make a difference in this case.
f1d87c8 simplewallet: add magic and public keys to key image export file (moneromooo-monero)
f4e894a simplewallet: make the key image export format binary (moneromooo-monero)
640a934 tests: cmake: fix building with system gtest (redfish)
4a9e949 tests: cmake: use a list for enabled tests (redfish)
dbd9a26 cmake: tests: gtest target is not always defined #983 (redfish)
Since this queries block heights for blocks that may or may not
exist, queries for non existing blocks would throw an exception,
and that would slow down the loop a lot. 7 seconds to go through
a 30 hash list.
Fix this by adding an optional return block height to block_exists
and using this instead. Actual errors will still throw an
exception.
This also cuts down on log exception spam.
CMake issued a warming about policy CMP0026: access of LOCATION
target property at config time was disallowed. Offending code
was the code that merged static libraries to generate
libwallet_merged.a.
This patch does that same merge task in a much simpler way. And,
since it doesn't violate the policy, the warning went away.
Access to LOCATION property at config time was disallowed by this
policy. This patch updates the offending code to comply with the policy
and thereby gets rid of the warning printed by cmake.
The fix is to use generator expressions instead of that property.
NOTE: Had to remove support for multiconfig (only affects MSVC which is
not supported anyway; and mutliconf is an IDE thing in any case),
because could not see how to support it with generator expressions.
The code used to cap at 5000 blocks per sync. It also treated 0 as 1.
Remove these checks; if specified as 0 do no periodic syncs at all.
Then the user is responsible for syncing in some external process.
