Commits on Nov 17, 2018

1. openjdk11: enable ZGC on x86_64-linux …

   The Z Garbage Collector is a concurrent, scalable, low latency garbage
   collector designed to meet extremely-low-pause-time requirements for
   small-to-multi-TB heap sizes.
   
   ZGC can be enabled with the magical incantation:
   
       $ java -XX:+UnlockExperimentalVMOptions -XX:+UseZGC ...
   
   Currently, ZGC is only available for x86_64-linux (though a port for
   aarch64-linux may become available at a future time.) There are also a
   number of other features that currently aren't present, such as JVMCI
   integration (meaning compiler tools like Graal which require JVMCI will
   not work with ZGC enabled.)
   
   Signed-off-by: Austin Seipp <aseipp@pobox.com>
   (cherry picked from commit 1629147)

   

   thoughtpolice committed Nov 17, 2018
   2

   Copy the full SHA

   5d0ef3f View commit details

   Browse the repository at this point in the history

2. foundationdb60: 6.0.4pre2497_73d64cb2 -> 6.0.11pre2716_9e8c1941e …

   Signed-off-by: Austin Seipp <aseipp@pobox.com>
   (cherry picked from commit f1737fa)

   

   thoughtpolice committed Nov 17, 2018
   Copy the full SHA

   1d3d52a View commit details

   Browse the repository at this point in the history

3. foundationdb: include fdb.options in .dev for binding generators …

   Signed-off-by: Austin Seipp <aseipp@pobox.com>
   (cherry picked from commit 32948a6)

   

   thoughtpolice committed Nov 17, 2018
   Copy the full SHA

   eec1fa5 View commit details

   Browse the repository at this point in the history

4. 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>
   (cherry picked from commit 6054dab)

   

   thoughtpolice committed Nov 17, 2018
   Copy the full SHA

   d359c39 View commit details

   Browse the repository at this point in the history

5. foundationdb60: 6.0.11pre2716 -> 6.0.15 …

   Signed-off-by: Austin Seipp <aseipp@pobox.com>
   (cherry picked from commit 8d4f8a6)

   

   thoughtpolice committed Nov 17, 2018
   Copy the full SHA

   0f7a562 View commit details

   Browse the repository at this point in the history