Go to file
Brian Behlendorf a7958f7eef Support custom build directories
One of the neat tricks an autoconf style project is capable of
is allow configurion/building in a directory other than the
source directory.  The major advantage to this is that you can
build the project various different ways while making changes
in a single source tree.

For example, this project is designed to work on various different
Linux distributions each of which work slightly differently.  This
means that changes need to verified on each of those supported
distributions perferably before the change is committed to the
public git repo.

Using nfs and custom build directories makes this much easier.
I now have a single source tree in nfs mounted on several different
systems each running a supported distribution.  When I make a
change to the source base I suspect may break things I can
concurrently build from the same source on all the systems each
in their own subdirectory.

wget -c http://github.com/downloads/behlendorf/spl/spl-x.y.z.tar.gz
tar -xzf spl-x.y.z.tar.gz
cd spl-x-y-z

------------------------- run concurrently ----------------------
<ubuntu system>  <fedora system>  <debian system>  <rhel6 system>
mkdir ubuntu     mkdir fedora     mkdir debian     mkdir rhel6
cd ubuntu        cd fedora        cd debian        cd rhel6
../configure     ../configure     ../configure     ../configure
make             make             make             make
make check       make check       make check       make check

This is something the project has almost supported for a long time
but finishing this support should save me lots of time.
2010-09-05 21:49:05 -07:00
cmd Support custom build directories 2010-09-05 21:49:05 -07:00
config Support custom build directories 2010-09-05 21:49:05 -07:00
include Support custom build directories 2010-09-05 21:49:05 -07:00
lib Support custom build directories 2010-09-05 21:49:05 -07:00
module Support custom build directories 2010-09-05 21:49:05 -07:00
patches Reimplement rwlocks for Linux lock profiling/analysis. 2009-09-18 16:09:47 -07:00
scripts Support custom build directories 2010-09-05 21:49:05 -07:00
.gitignore Ignore unsigned module build products 2010-03-11 14:29:17 -08:00
AUTHORS Public Release Prep 2010-05-17 15:18:00 -07:00
autogen.sh Public Release Prep 2010-05-17 15:18:00 -07:00
ChangeLog Prep for spl-0.5.0 tag 2010-08-13 09:33:50 -07:00
configure Support custom build directories 2010-09-05 21:49:05 -07:00
configure.ac Support custom build directories 2010-09-05 21:49:05 -07:00
COPYING Public Release Prep 2010-05-17 15:18:00 -07:00
DISCLAIMER Public Release Prep 2010-05-17 15:18:00 -07:00
INSTALL Public Release Prep 2010-05-17 15:18:00 -07:00
Makefile.am Support custom build directories 2010-09-05 21:49:05 -07:00
Makefile.in Support custom build directories 2010-09-05 21:49:05 -07:00
META Prep for spl-0.5.1 tag 2010-09-01 10:24:44 -07:00
README.markdown Add quick build instructions 2010-09-01 10:23:05 -07:00
spl_config.h.in Correctly handle rwsem_is_locked() behavior 2010-08-10 16:43:00 -07:00
spl-modules.spec.in Minor spec file cleanup for RHEL6 package dependency. 2010-05-21 11:53:49 -07:00
spl.spec.in Remove usage of the __id_u macro for portability. 2009-10-05 12:51:58 -07:00

The Solaris Porting Layer (SPL) is a Linux kernel module which provides many of the Solaris kernel APIs. This shim layer makes it possible to run Solaris kernel code in the Linux kernel with relatively minimal modification. This can be particularly useful when you want to track upstream Solaris development closely and dont want the overhead of maintaining a large patch which converts Solaris primitives to Linux primitives.

To build packages for your distribution:

$ ./configure $ make pkg

Full documentation for building, configuring, and using the SPL can be found at: http://wiki.github.com/behlendorf/spl/