* 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 git://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 (linux-nilfs@vger.kernel.org). First, please read the following documents (in short, follow Linux kernel development rules): http://lxr.linux.no/source/Documentation/CodingStyle http://lxr.linux.no/source/Documentation/SubmittingPatches 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.