about summary refs log tree commit diff
path: root/pkgs/servers/foundationdb
Commit message (Collapse)AuthorAge
* foundationdb: no clang, use default gccAustin Seipp2019-11-01
| | | | | | | These options should be experimental, and I'm keeping them off for now. This also avoids any ABI concerns between libraries, too. Signed-off-by: Austin Seipp <aseipp@pobox.com>
* foundationdb61: 6.1.10 -> 6.1.12Austin Seipp2019-11-01
| | | | Signed-off-by: Austin Seipp <aseipp@pobox.com>
* treewide: remove redundant recvolth2019-08-28
|
* treewide: name -> pname (easy cases) (#66585)volth2019-08-15
| | | | | | | | | treewide replacement of stdenv.mkDerivation rec { name = "*-${version}"; version = "*"; to pname
* treewide: use dontConfigureworldofpeace2019-07-01
|
* foundationdb61: 6.1.8 -> 6.1.10Austin Seipp2019-06-16
| | | | Signed-off-by: Austin Seipp <aseipp@pobox.com>
* treewide: remove unused variables (#63177)volth2019-06-16
| | | | | | * treewide: remove unused variables * making ofborg happy
* foundationdb61: 6.1.7pre4928_a990458e -> 6.1.8Austin Seipp2019-05-27
| | | | | | | This bumps the 6.1.x branch to the official 6.1.8 release. Also fixes a minor bug in the new CMake build (an invalid parameter passed to CMake) Signed-off-by: Austin Seipp <aseipp@pobox.com>
* foundationdb61: 6.1.6pre4898 -> 6.1.7pre4928Austin Seipp2019-05-21
| | | | | | | Also includes some minor, miscellaneous cleanups to the CMake build expression. Signed-off-by: Austin Seipp <aseipp@pobox.com>
* foundationdb: init 6.1.6pre4898_26fbbbf, cmake buildAustin Seipp2019-05-15
| | | | | | | This adds a new build of FoundationDB 6.1, using the new, much improved with CMake build system with fewer patches and rough edges. Signed-off-by: Austin Seipp <aseipp@pobox.com>
* foundationdb: refactor vsmake patch applicationAustin Seipp2019-05-15
| | | | Signed-off-by: Austin Seipp <aseipp@pobox.com>
* foundationdb: refactor 'vsmake' build system into its own file [NFC]Austin Seipp2019-05-15
| | | | | | | | | | | | | | | FoundationDB is currently in the process of migrating to CMake, and it will eventually be the only build system. In preparation for this, split off the current (somewhat nasty) builder into its own file, and allow default.nix to be more declarative -- containing only the main supported versions. Similarly, a cmake.nix file will be added later. There is no functional change here (NFC), only an organizational change (file moves, no hash changes). Signed-off-by: Austin Seipp <aseipp@pobox.com>
* foundationdb60: 6.0.17 -> 6.0.18Austin Seipp2019-02-12
| | | | | | Fixes numerous bugs in blobstore backup. Signed-off-by: Austin Seipp <aseipp@pobox.com>
* mono: only maintain major versions (mono4 & mono5)obadz2018-12-23
|
* foundationdb: x86_64-linux onlyAustin Seipp2018-12-04
| | | | Signed-off-by: Austin Seipp <aseipp@pobox.com>
* foundationdb60: 6.0.15 -> 6.0.17Austin Seipp2018-12-04
| | | | Signed-off-by: Austin Seipp <aseipp@pobox.com>
* foundationdb: set RELEASE=true for official buildsAustin Seipp2018-11-17
| | | | | | | This ensures the proper version is reported in the server status information; otherwise it has a '-PRERELEASE' suffix. Signed-off-by: Austin Seipp <aseipp@pobox.com>
* foundationdb60: 6.0.11pre2716 -> 6.0.15Austin Seipp2018-11-16
| | | | Signed-off-by: Austin Seipp <aseipp@pobox.com>
* foundationdb: rework python bindings, build systemAustin Seipp2018-11-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | FoundationDB uses Python at build time for some code generation. However, it also has the official python bindings inside the source code too, and the code for the Python bindings has some of it auto-generated at compile time. This made building python packages unattractive: we want to use the source code generated from the FoundationDB build, but we don't want to rebuild it. Previously we would override the 'python' input to the FoundationDB module, but this meant we would do a complete rebuild, as it was a necessary build time dependency, even though the resulting generated code itself would not change. Furthermore, FoundationDB versions < 6.0 don't properly support Python 3 *for the build system*, though the bindings supported it, so that caused build failures. But the first effect is the worst: it meant building separate python2 and python3 packages implied two complete rebuilds of a single FoundationDB version. This meant rather than 3 FDB builds, we'd do 3*N where N = the number of major Python versions we support. Finally, because we did not use pip to generate a wheel that we install with metadata recorded for the installation, the FoundationDB python package couldn't be used as an input to other setup.py-based packages: there would be no recorded metadata in the dist-info folder which would say this is the foundationdb package. This greatly limits its utility. To fix all this, we do a few things: - Apply some patches to fix the build system with Python 3.x for older FoundationDB versions. (This is nice if end-users have overridden the global Python version for some reason.) - Move python directly into nativeBuildInputs, so it is only a build time dependency. - Take the python source code from the ./bindings directory and tar it up use later after the build is done, so we get to keep the generated code. This is the new 'pythonsrc' output from the build. This code doesn't change based on whether or not the input or resulting package is using Python 2 or 3, it's totally deterministic. - The build system also patches up the python source code a little, so it can be installed directly with setup.py (it needs a little stuff that it normally expects the build system to do.) - Rework the python package to a separate file that uses buildPythonPackage directly. Because the source code is already prepared, it needs almost nothing else. Furthermore, this kills the override itself for the foundationdb package, meaning rebuilds are no longer needed. - This package is very simple and just uses foundationdb.pythonsrc as its source input. It also ensures a link to libfdb_c.so can be found by ctypes (using substituteInPlace) - python-packages.nix now just uses callPackage directly. The net effect of this is, most importantly, that python packages do not imply a full rebuild of the server source code: building python2 and python3 packages from a version of FoundationDB now does not need to override the foundationdb python input, reducing the number of needless builds. They instead just run setup.py with the given version as input. The second biggest effect is that wheel metadata is recorded correctly, meaning dependent-python-packages that want to use the FoundationDB bindings e.g. from PyPi should now work fine with buildPythonPackage. Signed-off-by: Austin Seipp <aseipp@pobox.com>
* foundationdb: include fdb.options in .dev for binding generatorsAustin Seipp2018-11-16
| | | | Signed-off-by: Austin Seipp <aseipp@pobox.com>
* foundationdb60: 6.0.4pre2497_73d64cb2 -> 6.0.11pre2716_9e8c1941eAustin Seipp2018-09-17
| | | | Signed-off-by: Austin Seipp <aseipp@pobox.com>
* foundationdb: install python bindingsAustin Seipp2018-08-04
| | | | Signed-off-by: Austin Seipp <aseipp@pobox.com>
* foundationdb60: 6.0.3pre2446 -> 6.0.4pre2497Austin Seipp2018-08-04
| | | | Signed-off-by: Austin Seipp <aseipp@pobox.com>
* foundationdb52: 5.2.6 -> 5.2.8Austin Seipp2018-08-04
| | | | Signed-off-by: Austin Seipp <aseipp@pobox.com>
* foundationdb60: 6.0.2pre2430 -> 6.0.3pre2446Austin Seipp2018-07-26
| | | | Signed-off-by: Austin Seipp <aseipp@pobox.com>
* foundationdb: include debug info in all buildsAustin Seipp2018-07-26
| | | | | | | This puts the debug information in a separate output, as expected. This allows meaningful symbol names to appear in DWARF-based tools like perf and gdb. Signed-off-by: Austin Seipp <aseipp@pobox.com>
* foundationdb: bump to 5.2.6, 6.0.2-preleaseAustin Seipp2018-07-20
| | | | Signed-off-by: Austin Seipp <aseipp@pobox.com>
* foundationdb: add 5.2.5 release, and new 6.0.0 snapshotAustin Seipp2018-07-03
| | | | | | | | | | | | This requires a bit of fiddling with the ldflags patches and reworking a few things about how the SCM info is configured. Ideally, not much more will change before the 6.0 release, I think... This also upgrades all FoundationDB packages to use the ordinary libressl expression (which is now at 2.7.x), and changes around a few other things, which will require a rebuild. Signed-off-by: Austin Seipp <aseipp@pobox.com>
* Revert "foundationdb: add 5.2.5 release, and new 6.0.0 snapshot"Sarah Brofeldt2018-07-02
| | | | | This reverts commit 1fa2503f9dba814eb23726a25642d2180ce791c3. Broke ofborg evals due to missing required argument sdvend49
* foundationdb: add 5.2.5 release, and new 6.0.0 snapshotAustin Seipp2018-07-02
| | | | | | | | | | | | This requires a bit of fiddling with the ldflags patches and reworking a few things about how the SCM info is configured. Ideally, not much more will change before the 6.0 release, I think... This also upgrades all FoundationDB packages to use the ordinary libressl expression (which is now at 2.7.x), and changes around a few other things, which will require a rebuild. Signed-off-by: Austin Seipp <aseipp@pobox.com>
* foundationdb: rename jar file to match upstreamAustin Seipp2018-05-05
| | | | | | | And don't install the fdb_java.so file: it's already included inside of the jar itself. Signed-off-by: Austin Seipp <aseipp@pobox.com>
* foundationdb: split into multiple, major-versioned packages to make upgrades ↵Austin Seipp2018-05-01
| | | | | | user-controllable Signed-off-by: Austin Seipp <aseipp@pobox.com>
* foundationdb: install the java client libraryAustin Seipp2018-05-01
| | | | Signed-off-by: Austin Seipp <aseipp@pobox.com>
* foundationdb: init at 5.1.7Austin Seipp2018-04-23
Signed-off-by: Austin Seipp <aseipp@pobox.com>
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-07-05 12:12:28 +0000