BuildingV2
Version 2.0 has made two major changes to how the source is built.
- The TIRPC library is now included as a git submodule of NFS Ganesha.
- Cmake is used for configuring the target build.
New users can set up a working directory with the command:
$ cd dir/for/git/repos $ git clone --recursive git://github.com/nfs-ganesha/nfs-ganesha.git
The --recursive option tells git to clone all the
submodules too. This will give you a working directory ready for
work. However, the default checkout may be master which may not be
what you want if you want the new V2.0 source in next.
You must initialize the submodule after clone if you did not use the
--recursive option. You must also do it after pulling a new
update or checking out a new branch.
Go to the root of your repository and enter:
$ git submodule update --init
- NOTE
- The current HEAD of the ntirpc directory is a piece of tracked state. Please do not commit a change to the state unintentionally.
Cmake can and does prefer to build out- of-source. In other words, your build tree is over here and your git source tree is over there. The Makefiles are created by Cmake in the build tree, the objects and targets are in the build tree but the source is referenced "over there". For example, in a Ganesha build, we would do:
$ cd some-build-sandbox $ rm -rf build_dir; mkdir build_dir $ cd build_dir $ cmake ~/git/nfs-ganesha/src
The build directory is now populated with all the necessary Makefile bits for the target. You can now do the compile/build:
$ make $ make install
This gets the build completely away from where the git repo is. Note that I have thoroughly scrubbed the area before doing the cmake. You can also build in-tree but this litters the git repo with extra files just like autotools. See the Cmake manual for the details and restrictions.
Building is a two step process. You first run Cmake to configure the build and then you do a conventional Make. You can do iterative development by editing files, including Cmake files CMakeLists.txt in the source tree and go back to the build directory and do a make. The makefile will do the right thing and re-run Cmake if you changed any configuration files. Your configuration and build parameters are preserved in the build tree so you only have to do the full configuration step once.
Unlike autotools where the build and source are in the same tree, having a separate build area allows you to do a couple of thing safely.
- You can delete the whole build tree at any time. Simply repeat the configuration step and you get it ll back. Your source is safely somewhere else. Be aware of which window/terminal you are in before doing an rm -rf however. Yes, I did that once so now I have the windows on separate monitors...
- You can easily build multiple configurations. Simply create one build directory, enter it, and run make with one set of parameters. Repeat in another build directory with a different set of parameters. Nice.
Cmake allows the setting of configuration parameters from the command line. You would use this in a similar way to how autotools works.
You can discover what you can tweak by doing the following:
$ mkdir tweaktest; cd tweaktest $ cmake -i ~/git/nfs-ganesha/src
This will enter you into a "wizard" configuration (no fancy GUI stuff). Simply step through the configuration and note what knobs and switches are available and what their defaults are. After this, you can explicitly change parameters from the command line. For example:
$ mkdir mybuild; cd mybuild
$ cmake -D_USE_9P=OFF -D_HANDLE_MAPPING=ON -DALLOCATOR=tcmalloc \
~/git/nfs-ganesha/src
This will disable a 9P build, use handle mapping in the PROXY fsal and pick the tcmalloc allocator.
There are two other variables of interest:
- CMAKE_BUILD_TYPE
- This is a global setting for the type of build. See the Cmake documentation for what this means. I have added a Maintainer type which forces strict compiles. It is what I intend to use on builds.
- BUILD_CONFIG
- This setting triggers the loading of a file in src/cmake/build_configurations. This is useful for having a canned configuration. There is only one file currently in use which will turn on every option available.
$ cmake -DCMAKE_BUILD_TYPE=Maintainer -DBUILD_CONFIG=everything \
~/git/nfs-ganesha/src
Look at src/cmake/build_configuration/everything.cmake to see what this turns on. If you want a custom, for say just a 9P server or only some features, create a file on the model of everything.cmake in that directory and then reference it on the command line. This eliminates the various shell scripts we have laying around... I stole this from the Mysql build where they use this trick to have things like 'redhat.cmake' and 'debian.cmake'.
This subsection describe how to compile some non-legacy FSALs
Ganesha can export a LUSTRE filesystem. In this case, the ganesga.nfsd process is to be run on a client node. Do not use a LUSTRE OSS or MDS for the memory pressure on the node could quick be too string. For compiling Lustre FSAL, you need to install the Lustre client rpm. This rpm is downloadable from https://downloads.hpdd.intel.com/public/lustre/ From there, go to the folder related to the version that you want to use, then inside the folder matching your distro and then inside the "client" subfolder. The rpm files reside in RPM/x86_64. Pickup the rpm matching the pattern lustre-client-<kernel></kernel>-<distro></distro>.x86_64.rpm
At the cmake step do
cmake -DUSE_FSAL_LUSTRE=ON ~/git/nfs-ganesha/src
With Lustre 2.7, Ganesha becomes capable of dealing with upcalls from FSAL (based on changelog records caught by the LCAP software). The Cmake trigger is then "USE_FSAL_LUSTRE_UP".
Fist step is building the libzfswrap packages. From the root if the Ganesha source tree do to contrib/libzfswrap . From there, do:
$ autoreconf --force --install $ ./configure && make && make rpms
Once libzfswrap are generated, you must install the libzfswrap, libzfswrap-utils and libzfswrap-devel rpms. Then compile the FSAL this way
$ cmake -DUSE_FSAL_ZFS=ON ~/git/nfs-ganesha/src