These include:
* Memoizing packed representations within Tuples
* Using longs instead of BigIntegers if possible
* As much as possible sticking to manipulating primitive types when using floats/doubles
StorageServer is getting close to 4KB on older gccs. However,
on some systems (for example Fedora) the storageServer actor
is already larger than 4KB. This results in a linker error.
Up unto here this code is only very rudiemantery tested.
This is a firest attempt of making cpack more user-friendly.
The basic idea is to generate a component for package type so
that we can have different paths depending on whether we build
an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package
config file will then chose the correct components to use.
In a later point this should make it possible to build these
with `make packages` and the ugly iteration with calling cmake
between each package would be obsolete. While this solution is
a bit more bloated, it is also much more flexible and it will be
much easier to use.
Another benefit is, that this will get rid of all warnings during
a cpack run
The native function `NativeFuture::Future_getError` now returns `null` when the error code is 0 instead of an `FDBException` with a "Success" message and an error code of 0. This was only used in two places within the codebase; those two places now check for `null` errors and treats them like successes.
Change removing_redundant_teams status name to
optimizing_team_collections.
The new name is more general and can be applied in the future
when we switch storage engines.
This changes makes a cmake build check for an existing
versions.h file in the source directory before it builds
anything else. If it finds it it will fail the build.
This is to prevent confusion when someone tries to use cmake
on a source directory where the old build system was used
before (as this is not supported).
I followed the instructions to build with CMake on Windows, but cmake complains about missing Python interpreter.
Installation Python 2.7.x solved the issue.
```
C:\Data\Git\GitHub\foundationdb\build>cmake -G "Visual Studio 15 2017 Win64" -DBOOST_ROOT=C:\Users\chevalier\Downloads\boost_1_67_0\boost_1_67_0 c:\data\git\github\foundationdb
-- C:/Data/Git/GitHub/foundationdb C:/Data/Git/GitHub/foundationdb/build
-- Could NOT find LibreSSL, try to set the path to LibreSSL root folder in the system variable LibreSSL_ROOT (missing: LIBRESSL_CRYPTO_LIBRARY LIBRESSL_SSL_LIBRARY LIBRESSL_TLS_LIBRARY LIBRESSL_INCLUDE_DIR)
-- LibreSSL NOT Found - Will compile without TLS Support
-- You can set LibreSSL_ROOT to the LibreSSL install directory to help cmake find it
-- Found JNI: C:/Program Files/Java/jdk-11.0.2/lib/jawt.lib (Required is at least version "1.8")
-- Found Java: C:/Program Files/Java/jdk-11.0.2/bin/java.exe (found suitable version "11.0.2", minimum required is "1.8") found components: Development
-- Could NOT find Python (missing: Python_EXECUTABLE Interpreter)
CMake Error at cmake/FDBComponents.cmake:46 (message):
Could not found a suitable python interpreter
Call Stack (most recent call first):
CMakeLists.txt:60 (include)
-- Configuring incomplete, errors occurred!
See also "C:/Data/Git/GitHub/foundationdb/build/CMakeFiles/CMakeOutput.log".
See also "C:/Data/Git/GitHub/foundationdb/build/CMakeFiles/CMakeError.log".
```
After installing python
```
...
-- Found Python: C:/Python27/python.exe (found version "2.7.16") found components: Interpreter
...
-- =========================================
-- Components Build Overview
-- =========================================
-- Build Java Bindings: ON
-- Build with TLS support: OFF
-- Build Go bindings: OFF
-- Build Ruby bindings: OFF
-- Build Python sdist (make package): ON
-- Build Documentation (make html): OFF
-- =========================================
-- CPACK_COMPONENTS_ALL
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Data/Git/GitHub/foundationdb/build
```
Alec Grieser