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
```
This is to give us a way to let which boost to use toggleable in the
source code as BOOSTDIR_BASENAME, and let build enviornments configure
where to find appropriately named boost folders via BOOSTDIR_BASEDIR.
This isn't pretty, and CMake's FindBoost is a far better way to do this,
but it'll work for now.
* Resolves#1027: Adding interfaces Database, ReadTransaction and Transaction.
* Moving implementations into DatabaseImpl and TransactionImpl.
* Also removed deprecated class Cluster.
As we changed the interfaces, especially how we create transaction, its
going to break the compilation of any app upgrades to this version of
flow bindings. It doesn't change any of the fdb_c APIs. So, backward
compatilbity with old servers is preserved through multi-version client.
* Fixing indentation
* Fixing format according to review comments.
In Linux, KAIO uses ASSERT to make sure open() flags have
OPEN_UNBUFFERED set.
In Windows, we uses if-condition and return io_errors() when the
flag is not set.
This PR makes Windoes implementation always use ASSERT to check the
flag.
mpilman