nilfs-dev / nilfs-utils

* Required packages

 - libuuid-devel or uuid-dev
 - libmount-devel or libmount-dev
 - libblkid-devel or libblkid-dev
 - libselinux-devel or libselinux1-dev
   (if /etc/mtab is a regular file and you use selinux context mount options)

* How to compile

 $ ./configure
 $ make

If your system is a 64-bit architecture and libraries are installed
into /usr/lib64 instead of /usr/lib, change the library directory with
--libdir option:

 $ ./configure --libdir=/usr/lib64

If /etc/mtab is not a symlink to /proc/self/mounts but a regular file
in the target system, run the configure script with --without-libmount
option:

 $ ./configure --without-libmount

This configures the build environment so as to make legacy
mount/umount helpers (mount.nilfs2 and umount.nilfs2), in which the
legacy mtab file is handled properly.  For CentOS 6 (and other RHEL 6
clones), for instance, this options is needed.

* Trouble shooting

If the blkid library in your environment is old and unusable to this
package, you can use --without-blkid option:

 $ ./configure --without-blkid

However, use of this option is normally not recommended because it
disables the safety check of mkfs.nilfs2 which prevents users from
unexpectedly overwriting an in-use device.

You can compile legacy mount.nilfs2 and umount.nilfs2 without support
of selinux context mount options (-o context=<context>, etc):

 $ ./configure --without-libmount --without-selinux

For helpers built with mount library (libmount), support of the
context mount depends on the libmount that distro provides.


* How to get development sources

 $ cd your-work-directory
 $ git clone https://github.com/nilfs-dev/nilfs-utils.git

Before compiling the development sources, you need to run autogen.sh
script.  This is not required for packaged sources unless you changed
the configuration.
 
 $ cd nilfs-utils
 $ ./autogen.sh

* Developer's notes

The central resource for nilfs-utils development is the mailing list
([email protected]).

First, please read the following documents (in short, follow Linux
kernel development rules):

https://docs.kernel.org/process/coding-style.html
https://docs.kernel.org/process/submitting-patches.html

Then, check your patches with the patch style checker prior to
submission (scripts/checkpatch.pl) like the following example:

 $ ./scripts/checkpatch.pl <patch-file>
 ...
 <patch-file> has no obvious style problems and is ready for submission.