Commit Graph

22 Commits

Author SHA1 Message Date
Austin Seipp
c19807e25d
foundationdb60: 6.0.17 -> 6.0.18
Fixes numerous bugs in blobstore backup.

Signed-off-by: Austin Seipp <aseipp@pobox.com>
2019-02-12 23:03:25 -06:00
obadz
55af73e156 mono: only maintain major versions (mono4 & mono5) 2018-12-23 00:04:46 +00:00
Austin Seipp
3ebdd65ad7 foundationdb: x86_64-linux only
Signed-off-by: Austin Seipp <aseipp@pobox.com>
2018-12-04 22:32:54 -06:00
Austin Seipp
c9fd7dc0ee foundationdb60: 6.0.15 -> 6.0.17
Signed-off-by: Austin Seipp <aseipp@pobox.com>
2018-12-04 22:32:54 -06:00
Austin Seipp
47b3086bdf foundationdb: set RELEASE=true for official builds
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>
2018-11-17 22:12:40 -06:00
Austin Seipp
8d4f8a6d26 foundationdb60: 6.0.11pre2716 -> 6.0.15
Signed-off-by: Austin Seipp <aseipp@pobox.com>
2018-11-16 20:34:20 -06:00
Austin Seipp
6054dabc11 foundationdb: rework python bindings, build system
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>
2018-11-16 20:34:19 -06:00
Austin Seipp
32948a6f3d foundationdb: include fdb.options in .dev for binding generators
Signed-off-by: Austin Seipp <aseipp@pobox.com>
2018-11-16 20:22:40 -06:00
Austin Seipp
f1737fa646 foundationdb60: 6.0.4pre2497_73d64cb2 -> 6.0.11pre2716_9e8c1941e
Signed-off-by: Austin Seipp <aseipp@pobox.com>
2018-09-17 17:49:09 -05:00
Austin Seipp
aa79ae0c64 foundationdb: install python bindings
Signed-off-by: Austin Seipp <aseipp@pobox.com>
2018-08-04 16:56:16 -05:00
Austin Seipp
6b0451c060 foundationdb60: 6.0.3pre2446 -> 6.0.4pre2497
Signed-off-by: Austin Seipp <aseipp@pobox.com>
2018-08-04 09:47:41 -05:00
Austin Seipp
d8652e9fc2 foundationdb52: 5.2.6 -> 5.2.8
Signed-off-by: Austin Seipp <aseipp@pobox.com>
2018-08-04 09:47:41 -05:00
Austin Seipp
f8e8ecde51 foundationdb60: 6.0.2pre2430 -> 6.0.3pre2446
Signed-off-by: Austin Seipp <aseipp@pobox.com>
2018-07-26 18:58:40 -05:00
Austin Seipp
a14a75a567 foundationdb: include debug info in all builds
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>
2018-07-26 18:44:49 -05:00
Austin Seipp
f517b5a8dd foundationdb: bump to 5.2.6, 6.0.2-prelease
Signed-off-by: Austin Seipp <aseipp@pobox.com>
2018-07-20 17:57:44 -05:00
Austin Seipp
e42e0c8179 foundationdb: add 5.2.5 release, and new 6.0.0 snapshot
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>
2018-07-03 09:09:02 -05:00
Sarah Brofeldt
6abb68d47a Revert "foundationdb: add 5.2.5 release, and new 6.0.0 snapshot"
This reverts commit 1fa2503f9d.
Broke ofborg evals due to missing required argument sdvend49
2018-07-02 16:08:54 +02:00
Austin Seipp
1fa2503f9d foundationdb: add 5.2.5 release, and new 6.0.0 snapshot
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>
2018-07-02 06:48:41 -05:00
Austin Seipp
34a71a80b8 foundationdb: rename jar file to match upstream
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>
2018-05-05 01:30:15 -05:00
Austin Seipp
5a24d99fa6 foundationdb: split into multiple, major-versioned packages to make upgrades user-controllable
Signed-off-by: Austin Seipp <aseipp@pobox.com>
2018-05-01 15:47:36 -05:00
Austin Seipp
ed5cbbbc44 foundationdb: install the java client library
Signed-off-by: Austin Seipp <aseipp@pobox.com>
2018-05-01 15:47:36 -05:00
Austin Seipp
617db2df96 foundationdb: init at 5.1.7
Signed-off-by: Austin Seipp <aseipp@pobox.com>
2018-04-23 12:12:53 -05:00