From 9ef3c08880858407aea4dcf93c10b1750b0da2ee Mon Sep 17 00:00:00 2001 From: AJ Jordan Date: Wed, 7 Oct 2020 15:48:56 -0400 Subject: [PATCH] Remove references to separate SPL repository --- docs/Developer Resources/Building ZFS.rst | 74 ++++++++--------------- 1 file changed, 24 insertions(+), 50 deletions(-) diff --git a/docs/Developer Resources/Building ZFS.rst b/docs/Developer Resources/Building ZFS.rst index 17a3452..7b4f6cf 100644 --- a/docs/Developer Resources/Building ZFS.rst +++ b/docs/Developer Resources/Building ZFS.rst @@ -5,25 +5,24 @@ GitHub Repositories ~~~~~~~~~~~~~~~~~~~ The official source for ZFS on Linux is maintained at GitHub by the -`openzfs `__ organization. The project -consists of two primary git repositories named `spl -`__ and `zfs -`__, both are required to build ZFS on -Linux. +`openzfs `__ organization. The primary +git repository for the project is the `zfs +`__ repository. -**NOTE:** The SPL was merged in to the -`zfs `__ repository, the last major -release with a separate SPL is ``0.7``. - -- **SPL**: The SPL is thin shim layer which is responsible for - implementing the fundamental interfaces required by OpenZFS. It's - this layer which allows OpenZFS to be used across multiple platforms. +There are two main components in this repository: - **ZFS**: The ZFS repository contains a copy of the upstream OpenZFS code which has been adapted and extended for Linux and FreeBSD. The vast majority of the core OpenZFS code is self-contained and can be used without modification. +- **SPL**: The SPL is thin shim layer which is responsible for + implementing the fundamental interfaces required by OpenZFS. It's + this layer which allows OpenZFS to be used across multiple + platforms. SPL used to be maintained in a separate repository, but + was merged into the `zfs `__ + repository in the ``0.8`` major release. + Installing Dependencies ~~~~~~~~~~~~~~~~~~~~~~~ @@ -67,11 +66,11 @@ depends on your requirements. downside to using packages it is greatly increases the time required to build, install, and test a change. -- **In-tree**: Development can be done entirely in the SPL and ZFS - source trees. This speeds up development by allowing developers to - rapidly iterate on a patch. When working in-tree developers can - leverage incremental builds, load/unload kernel modules, execute - utilities, and verify all their changes with the ZFS Test Suite. +- **In-tree**: Development can be done entirely in the SPL/ZFS source + tree. This speeds up development by allowing developers to rapidly + iterate on a patch. When working in-tree developers can leverage + incremental builds, load/unload kernel modules, execute utilities, + and verify all their changes with the ZFS Test Suite. The remainder of this page focuses on the **in-tree** option which is the recommended method of development for the majority of changes. See @@ -84,28 +83,17 @@ Developing In-Tree Clone from GitHub ^^^^^^^^^^^^^^^^^ -Start by cloning the SPL and ZFS repositories from GitHub. The -repositories have a **master** branch for development and a series of -**\*-release** branches for tagged releases. After checking out the -repository your clone will default to the master branch. Tagged releases -may be built by checking out spl/zfs-x.y.z tags with matching version -numbers or matching release branches. Avoid using mismatched versions, -this can result build failures due to interface changes. - -**NOTE:** SPL was merged in to the -`zfs `__ repository, last release -with separate SPL is ``0.7``. +Start by cloning the ZFS repository from GitHub. The repository has a +**master** branch for development and a series of **\*-release** +branches for tagged releases. After checking out the repository your +clone will default to the master branch. Tagged releases may be built +by checking out zfs-x.y.z tags with matching version numbers or +matching release branches. :: git clone https://github.com/openzfs/zfs -If you need 0.7 release or older: - -:: - - git clone https://github.com/openzfs/spl - Configure and Build ^^^^^^^^^^^^^^^^^^^ @@ -118,20 +106,9 @@ defects as early as possible and to keep them out of the tree. Developers should be comfortable frequently rebasing their work against the latest master branch. -If you want to build 0.7 release or older, you should compile SPL first: - -:: - - cd ./spl - git checkout master - sh autogen.sh - ./configure - make -s -j$(nproc) - In this example we'll use the master branch and walk through a stock -**in-tree** build, so we don't need to build SPL separately. Start by -checking out the desired branch then build the ZFS and SPL source in the -tradition autotools fashion. +**in-tree** build. Start by checking out the desired branch then build +the ZFS and SPL source in the tradition autotools fashion. :: @@ -147,9 +124,6 @@ tradition autotools fashion. | **tip:** ``--enable-debug`` can be set to enable all ASSERTs and additional correctness tests. This option is also supported when building ZFS. -| **tip:** for version ``<=0.7`` ``--with-spl=PATH`` and - ``--with-spl-obj=PATH``, where ``PATH`` is a full path, can be passed - to configure if it is unable to locate the SPL. **Optional** Build packages