Archive-Team
/
zfs
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 103 Wiki Activity
zfs/config/zfs-build.m4

286 lines
7.2 KiB
Plaintext
Raw Permalink Normal View History

Refresh zfs-branch
2008-12-05 17:46:11 +00:00
AC_DEFUN([ZFS_AC_LICENSE], [
Configure checks for kernel build options incompatible with the license Twice now I've been bitten by building agaist a kernel which is configured such that it is incompatible with the CDDL license. These build failures don't occur until the linking phase at which point they simply callout the offending symbol. No location information can be provided at this point so it often can be confusing what the problem is particularly when building against a new kernel for the first time. To help address this I've added a configure check which can be extended over time to detect known kernel config options which if set will break the ZFS build. Currently I have just added CONFIG_DEBUG_LOCK_ALLOC which makes mutex's GPL-only and is on by default in the RHEL6 alpha builds. I know for a fact there are other similiar options which can be added as they are encountered.
2010-03-08 18:27:42 +00:00
AC_MSG_CHECKING([zfs author])
AC_MSG_RESULT([$ZFS_META_AUTHOR])
Build system and packaging (RPM support) (Part 1) An update to the build system to properly support all commonly used Makefile targets these include: make all # Build everything make install # Install everything make clean # Clean up build products make distclean # Clean up everything make dist # Create package tarball make srpm # Create package source RPM make rpm # Create package binary RPMs make tags # Create ctags and etags for everything Extra care was taken to ensure that the source RPMs are fully rebuildable against Fedora/RHEL/Chaos kernels. To build binary RPMs from the source RPM for your system simply run: rpmbuild --rebuild zfs-x.y.z-1.src.rpm This will produce two binary RPMs with correct 'requires' dependencies for your kernel. One will contain all zfs modules and support utilities, the other is a devel package for compiling additional kernel modules which are dependant on the zfs. zfs-x.y.z-1_<kernel version>.x86_64.rpm zfs-devel-x.y.2-1_<kernel version>.x86_64.rpm
2009-03-10 18:10:50 +00:00
Configure checks for kernel build options incompatible with the license Twice now I've been bitten by building agaist a kernel which is configured such that it is incompatible with the CDDL license. These build failures don't occur until the linking phase at which point they simply callout the offending symbol. No location information can be provided at this point so it often can be confusing what the problem is particularly when building against a new kernel for the first time. To help address this I've added a configure check which can be extended over time to detect known kernel config options which if set will break the ZFS build. Currently I have just added CONFIG_DEBUG_LOCK_ALLOC which makes mutex's GPL-only and is on by default in the RHEL6 alpha builds. I know for a fact there are other similiar options which can be added as they are encountered.
2010-03-08 18:27:42 +00:00
AC_MSG_CHECKING([zfs license])
AC_MSG_RESULT([$ZFS_META_LICENSE])
Refresh zfs-branch
2008-12-05 17:46:11 +00:00
])
AC_DEFUN([ZFS_AC_DEBUG], [
Move build system and core script changes to correct zfs-branch.
2010-05-18 22:05:44 +00:00
AC_MSG_CHECKING([whether debugging is enabled])
Only make compiler warnings fatal with --enable-debug While in theory I like the idea of compiler warnings always being fatal. In practice this causes problems when small harmless errors cause build failures for end users. To handle this I've updated the build system such that -Werror is only used when --enable-debug is passed to configure. This is how I always build when developing so I'll catch all build warnings and end users will not get stuck by minor issues.
2010-07-14 17:25:54 +00:00
AC_ARG_ENABLE([debug],
[AS_HELP_STRING([--enable-debug],
[Enable generic debug support @<:@default=no@:>@])],
[],
[enable_debug=no])
AS_IF([test "x$enable_debug" = xyes],
[
KERNELCPPFLAGS="${KERNELCPPFLAGS} -DDEBUG -Werror"
HOSTCFLAGS="${HOSTCFLAGS} -DDEBUG -Werror"
Restrict usage of -fstack-check option The stack check implementation in older versions of gcc has a fairly low default limit on STACK_CHECK_MAX_FRAME_SIZE of roughly 4096. This results in numerous warning when it is used with code which was designed to run in user space and thus may be relatively stack heavy. The avoid these warnings, which are fatal with -Werror, this patch targets the use of -fstack-check to libraries which are compiled in both user space and kernel space. The only utility which uses this flag is ztest which is designed to simulate running in the kernel and must meet the -fstack-check requirements. All other user space utilities do not use -fstack-check. warning: frame size too large for reliable stack checking warning: try reducing the number of local variables
2010-07-23 17:13:59 +00:00
DEBUG_CFLAGS="-DDEBUG -Werror"
DEBUG_STACKFLAGS="-fstack-check"
Only make compiler warnings fatal with --enable-debug While in theory I like the idea of compiler warnings always being fatal. In practice this causes problems when small harmless errors cause build failures for end users. To handle this I've updated the build system such that -Werror is only used when --enable-debug is passed to configure. This is how I always build when developing so I'll catch all build warnings and end users will not get stuck by minor issues.
2010-07-14 17:25:54 +00:00
],
[
Move build system and core script changes to correct zfs-branch.
2010-05-18 22:05:44 +00:00
KERNELCPPFLAGS="${KERNELCPPFLAGS} -DNDEBUG "
Refresh zfs-branch
2008-12-05 17:46:11 +00:00
HOSTCFLAGS="${HOSTCFLAGS} -DNDEBUG "
Only make compiler warnings fatal with --enable-debug While in theory I like the idea of compiler warnings always being fatal. In practice this causes problems when small harmless errors cause build failures for end users. To handle this I've updated the build system such that -Werror is only used when --enable-debug is passed to configure. This is how I always build when developing so I'll catch all build warnings and end users will not get stuck by minor issues.
2010-07-14 17:25:54 +00:00
DEBUG_CFLAGS="-DNDEBUG"
Restrict usage of -fstack-check option The stack check implementation in older versions of gcc has a fairly low default limit on STACK_CHECK_MAX_FRAME_SIZE of roughly 4096. This results in numerous warning when it is used with code which was designed to run in user space and thus may be relatively stack heavy. The avoid these warnings, which are fatal with -Werror, this patch targets the use of -fstack-check to libraries which are compiled in both user space and kernel space. The only utility which uses this flag is ztest which is designed to simulate running in the kernel and must meet the -fstack-check requirements. All other user space utilities do not use -fstack-check. warning: frame size too large for reliable stack checking warning: try reducing the number of local variables
2010-07-23 17:13:59 +00:00
DEBUG_STACKFLAGS=""
Only make compiler warnings fatal with --enable-debug While in theory I like the idea of compiler warnings always being fatal. In practice this causes problems when small harmless errors cause build failures for end users. To handle this I've updated the build system such that -Werror is only used when --enable-debug is passed to configure. This is how I always build when developing so I'll catch all build warnings and end users will not get stuck by minor issues.
2010-07-14 17:25:54 +00:00
])
Move build system and core script changes to correct zfs-branch.
2010-05-18 22:05:44 +00:00
Only make compiler warnings fatal with --enable-debug While in theory I like the idea of compiler warnings always being fatal. In practice this causes problems when small harmless errors cause build failures for end users. To handle this I've updated the build system such that -Werror is only used when --enable-debug is passed to configure. This is how I always build when developing so I'll catch all build warnings and end users will not get stuck by minor issues.
2010-07-14 17:25:54 +00:00
AC_SUBST(DEBUG_CFLAGS)
Restrict usage of -fstack-check option The stack check implementation in older versions of gcc has a fairly low default limit on STACK_CHECK_MAX_FRAME_SIZE of roughly 4096. This results in numerous warning when it is used with code which was designed to run in user space and thus may be relatively stack heavy. The avoid these warnings, which are fatal with -Werror, this patch targets the use of -fstack-check to libraries which are compiled in both user space and kernel space. The only utility which uses this flag is ztest which is designed to simulate running in the kernel and must meet the -fstack-check requirements. All other user space utilities do not use -fstack-check. warning: frame size too large for reliable stack checking warning: try reducing the number of local variables
2010-07-23 17:13:59 +00:00
AC_SUBST(DEBUG_STACKFLAGS)
Only make compiler warnings fatal with --enable-debug While in theory I like the idea of compiler warnings always being fatal. In practice this causes problems when small harmless errors cause build failures for end users. To handle this I've updated the build system such that -Werror is only used when --enable-debug is passed to configure. This is how I always build when developing so I'll catch all build warnings and end users will not get stuck by minor issues.
2010-07-14 17:25:54 +00:00
AC_MSG_RESULT([$enable_debug])
Refresh zfs-branch
2008-12-05 17:46:11 +00:00
])
AC_DEFUN([ZFS_AC_CONFIG_SCRIPT], [
Add zfs-test package which includes test infrastructure. This change extends the existing in-tree test infrastructure such that it can also be run as part of a the installed package. This simplifies testing on multiple systems and is generally all around useful. The scripts may still be run in-tree and will use the in-tree build products as long as .script-config exists.
2009-08-18 04:35:06 +00:00
cat >.script-config <<EOF
KERNELSRC=${LINUX}
KERNELBUILD=${LINUX_OBJ}
KERNELSRCVER=${LINUX_VERSION}
KERNELMOD=/lib/modules/\${KERNELSRCVER}/kernel
SPLSRC=${SPL}
SPLBUILD=${SPL_OBJ}
SPLSRCVER=${SPL_VERSION}
TOPDIR=${TOPDIR}
BUILDDIR=${BUILDDIR}
LIBDIR=${LIBDIR}
CMDDIR=${CMDDIR}
MODDIR=${MODDIR}
SCRIPTDIR=${SCRIPTDIR}
Split the udev rule from a specific configuration While I completely agree the udev is the lesser of many possibles evils when solving the device issue... it is still evil. After attempting to craft a single rule which will work for various versions of udev in various distros. I've come to the conclusion the only maintainable way to solve this issue is to split the rule from any particular configuration. This commit provides a generic 60-zpool.rules file which use a small helper util 'zpool_id' to parse a configuration file by default located in /etc/zfs/zdev.conf. The helper script maps a by-path udev name to a more friendly name of <channel><rank> for large configurations. As part of this change all of the support scripts why rely on this udev naming convention have been updated as needed. Example zdev.conf files have also been added for 3 different systems by you will always need to add one for your exact hardware. Finally, included in these changes are the proper tweaks to the build system to ensure everything still get's packaged properly in the rpms and can run in or out of tree.
2010-03-02 00:45:31 +00:00
ETCDIR=\${TOPDIR}/etc
Remove udev dependency when running in-tree After much contemplation I can't see a clean way to use udev entirely in-tree for testing. This patch removed a horrible horrible hack which would copy the needed udev bits in to place on your system to make it work. That however is simply not acceptable, nothing you in in-tree should ever ever ever install something on your system. Since I could not come up with a clean way to use udev in-tree. The fix is to simply parse the zdev config file and create the needed symlinks in a sub-diretory or your working tree. This is not as clean as using udev but it does work perfectly well for in-tree testing.
2010-03-11 21:56:20 +00:00
DEVDIR=\${TOPDIR}/dev
Add zfs-test package which includes test infrastructure. This change extends the existing in-tree test infrastructure such that it can also be run as part of a the installed package. This simplifies testing on multiple systems and is generally all around useful. The scripts may still be run in-tree and will use the in-tree build products as long as .script-config exists.
2009-08-18 04:35:06 +00:00
ZPOOLDIR=\${TOPDIR}/scripts/zpool-config
Add zpios scripts to zfs-test package test infrastructure. This change extends the existing in-tree test infrastructure such that it can also be run as part of a the installed package. This simplifies testing on multiple systems and is generally all around useful. The scripts may still be run in-tree and will use the in-tree build products as long as .script-config exists.
2009-08-18 04:50:55 +00:00
ZPIOSDIR=\${TOPDIR}/scripts/zpios-test
ZPIOSPROFILEDIR=\${TOPDIR}/scripts/zpios-profile
Add zfs-test package which includes test infrastructure. This change extends the existing in-tree test infrastructure such that it can also be run as part of a the installed package. This simplifies testing on multiple systems and is generally all around useful. The scripts may still be run in-tree and will use the in-tree build products as long as .script-config exists.
2009-08-18 04:35:06 +00:00
ZDB=\${CMDDIR}/zdb/zdb
ZFS=\${CMDDIR}/zfs/zfs
ZINJECT=\${CMDDIR}/zinject/zinject
ZPOOL=\${CMDDIR}/zpool/zpool
Split the udev rule from a specific configuration While I completely agree the udev is the lesser of many possibles evils when solving the device issue... it is still evil. After attempting to craft a single rule which will work for various versions of udev in various distros. I've come to the conclusion the only maintainable way to solve this issue is to split the rule from any particular configuration. This commit provides a generic 60-zpool.rules file which use a small helper util 'zpool_id' to parse a configuration file by default located in /etc/zfs/zdev.conf. The helper script maps a by-path udev name to a more friendly name of <channel><rank> for large configurations. As part of this change all of the support scripts why rely on this udev naming convention have been updated as needed. Example zdev.conf files have also been added for 3 different systems by you will always need to add one for your exact hardware. Finally, included in these changes are the proper tweaks to the build system to ensure everything still get's packaged properly in the rpms and can run in or out of tree.
2010-03-02 00:45:31 +00:00
ZPOOL_ID=\${CMDDIR}/zpool_id/zpool_id
Add zfs-test package which includes test infrastructure. This change extends the existing in-tree test infrastructure such that it can also be run as part of a the installed package. This simplifies testing on multiple systems and is generally all around useful. The scripts may still be run in-tree and will use the in-tree build products as long as .script-config exists.
2009-08-18 04:35:06 +00:00
ZTEST=\${CMDDIR}/ztest/ztest
Add zpios scripts to zfs-test package test infrastructure. This change extends the existing in-tree test infrastructure such that it can also be run as part of a the installed package. This simplifies testing on multiple systems and is generally all around useful. The scripts may still be run in-tree and will use the in-tree build products as long as .script-config exists.
2009-08-18 04:50:55 +00:00
ZPIOS=\${CMDDIR}/zpios/zpios
Add zfs-test package which includes test infrastructure. This change extends the existing in-tree test infrastructure such that it can also be run as part of a the installed package. This simplifies testing on multiple systems and is generally all around useful. The scripts may still be run in-tree and will use the in-tree build products as long as .script-config exists.
2009-08-18 04:35:06 +00:00
COMMON_SH=\${SCRIPTDIR}/common.sh
ZFS_SH=\${SCRIPTDIR}/zfs.sh
ZPOOL_CREATE_SH=\${SCRIPTDIR}/zpool-create.sh
Add zpios scripts to zfs-test package test infrastructure. This change extends the existing in-tree test infrastructure such that it can also be run as part of a the installed package. This simplifies testing on multiple systems and is generally all around useful. The scripts may still be run in-tree and will use the in-tree build products as long as .script-config exists.
2009-08-18 04:50:55 +00:00
ZPIOS_SH=\${SCRIPTDIR}/zpios.sh
ZPIOS_SURVEY_SH=\${SCRIPTDIR}/zpios-survey.sh
Add zfs-test package which includes test infrastructure. This change extends the existing in-tree test infrastructure such that it can also be run as part of a the installed package. This simplifies testing on multiple systems and is generally all around useful. The scripts may still be run in-tree and will use the in-tree build products as long as .script-config exists.
2009-08-18 04:35:06 +00:00
Remove udev dependency when running in-tree After much contemplation I can't see a clean way to use udev entirely in-tree for testing. This patch removed a horrible horrible hack which would copy the needed udev bits in to place on your system to make it work. That however is simply not acceptable, nothing you in in-tree should ever ever ever install something on your system. Since I could not come up with a clean way to use udev in-tree. The fix is to simply parse the zdev config file and create the needed symlinks in a sub-diretory or your working tree. This is not as clean as using udev but it does work perfectly well for in-tree testing.
2010-03-11 21:56:20 +00:00
INTREE=1
Add zfs-test package which includes test infrastructure. This change extends the existing in-tree test infrastructure such that it can also be run as part of a the installed package. This simplifies testing on multiple systems and is generally all around useful. The scripts may still be run in-tree and will use the in-tree build products as long as .script-config exists.
2009-08-18 04:35:06 +00:00
LDMOD=/sbin/insmod
KERNEL_MODULES=( \\
\${KERNELMOD}/lib/zlib_deflate/zlib_deflate.ko \\
)
SPL_MODULES=( \\
\${SPLBUILD}/spl/spl.ko \\
Add splat module to zfs.sh script The splat module is only needed for the spl regression tests. But if we add it to MODULES then 'zfs.sh -u' will be able to unload it if needed, The downside if 'zfs.sh' will always load it but it's overhead is minimal and in a production setting you'll always be doing a 'modprobe zfs' anyway so this is really just for testing.
2010-07-28 22:02:27 +00:00
\${SPLBUILD}/splat/splat.ko \\
Add zfs-test package which includes test infrastructure. This change extends the existing in-tree test infrastructure such that it can also be run as part of a the installed package. This simplifies testing on multiple systems and is generally all around useful. The scripts may still be run in-tree and will use the in-tree build products as long as .script-config exists.
2009-08-18 04:35:06 +00:00
)
ZFS_MODULES=( \\
\${MODDIR}/avl/zavl.ko \\
\${MODDIR}/nvpair/znvpair.ko \\
\${MODDIR}/unicode/zunicode.ko \\
\${MODDIR}/zcommon/zcommon.ko \\
\${MODDIR}/zfs/zfs.ko \\
)
Add zpios scripts to zfs-test package test infrastructure. This change extends the existing in-tree test infrastructure such that it can also be run as part of a the installed package. This simplifies testing on multiple systems and is generally all around useful. The scripts may still be run in-tree and will use the in-tree build products as long as .script-config exists.
2009-08-18 04:50:55 +00:00
ZPIOS_MODULES=( \\
\${MODDIR}/zpios/zpios.ko \\
)
Add zfs-test package which includes test infrastructure. This change extends the existing in-tree test infrastructure such that it can also be run as part of a the installed package. This simplifies testing on multiple systems and is generally all around useful. The scripts may still be run in-tree and will use the in-tree build products as long as .script-config exists.
2009-08-18 04:35:06 +00:00
MODULES=( \\
\${KERNEL_MODULES[[*]]} \\
\${SPL_MODULES[[*]]} \\
\${ZFS_MODULES[[*]]} \\
)
EOF
Refresh zfs-branch
2008-12-05 17:46:11 +00:00
])
AC_DEFUN([ZFS_AC_CONFIG], [
Distro friendly build system / packaging improvements. These changes bring the zfs-0.4.4 tree in to compliance with the spl-0.4.4 packaging changes. The bottom line is 2 source rpms and 4 binary rpms will now be generated when creating packages there will be: zfs-<version>.src.rpm - Fully rebuildable source rpm for libzfs and utils. zfs-modules-<version>.src.rpm - Fully rebuildable source rpm for kernel modules. zfs-<version>.<arch>.rpm - Binary rpm for libzfs and utils. The utils in this package are compatible with all zfs-module rpms of the same version. zfs-devel-<version>.<arch>.rpm - Binary rpm containing headers for building against libzfs libraries. zfs-modules-<verion>-<kernel>.arch.rpm - Binary rpm containing the kernel modules for a specific kernel build. The package name contains the kernel version and you should have one of these packages installed to match every kernel on your system. zfs-modules-devel-<verion>-<kernel>.arch.rpm - Binary rpm containing development header and module symbols needed for building additional kernel modules which are dependent on the zfs module stack. Expect minor interations on these changes as I validate they work properly on CHAOS, RHEL, Fedora, and SLES style distros.
2009-07-01 17:53:05 +00:00
TOPDIR=`readlink -f ${srcdir}`
Add MODDIR directory
2008-12-23 19:06:08 +00:00
BUILDDIR=$TOPDIR
LIBDIR=$TOPDIR/lib
CMDDIR=$TOPDIR/cmd
MODDIR=$TOPDIR/module
Add zfs-test package which includes test infrastructure. This change extends the existing in-tree test infrastructure such that it can also be run as part of a the installed package. This simplifies testing on multiple systems and is generally all around useful. The scripts may still be run in-tree and will use the in-tree build products as long as .script-config exists.
2009-08-18 04:35:06 +00:00
SCRIPTDIR=$TOPDIR/scripts
Add 'srpm' --with-config option for creation of spec files.
2009-11-24 22:13:25 +00:00
TARGET_ASM_DIR=asm-generic
Refresh zfs-branch
2008-12-05 17:46:11 +00:00
AC_SUBST(TOPDIR)
AC_SUBST(BUILDDIR)
AC_SUBST(LIBDIR)
AC_SUBST(CMDDIR)
Add MODDIR directory
2008-12-23 19:06:08 +00:00
AC_SUBST(MODDIR)
Add zfs-test package which includes test infrastructure. This change extends the existing in-tree test infrastructure such that it can also be run as part of a the installed package. This simplifies testing on multiple systems and is generally all around useful. The scripts may still be run in-tree and will use the in-tree build products as long as .script-config exists.
2009-08-18 04:35:06 +00:00
AC_SUBST(SCRIPTDIR)
Add 'srpm' --with-config option for creation of spec files.
2009-11-24 22:13:25 +00:00
AC_SUBST(TARGET_ASM_DIR)
Refresh zfs-branch
2008-12-05 17:46:11 +00:00
Distro friendly build system / packaging improvements. These changes bring the zfs-0.4.4 tree in to compliance with the spl-0.4.4 packaging changes. The bottom line is 2 source rpms and 4 binary rpms will now be generated when creating packages there will be: zfs-<version>.src.rpm - Fully rebuildable source rpm for libzfs and utils. zfs-modules-<version>.src.rpm - Fully rebuildable source rpm for kernel modules. zfs-<version>.<arch>.rpm - Binary rpm for libzfs and utils. The utils in this package are compatible with all zfs-module rpms of the same version. zfs-devel-<version>.<arch>.rpm - Binary rpm containing headers for building against libzfs libraries. zfs-modules-<verion>-<kernel>.arch.rpm - Binary rpm containing the kernel modules for a specific kernel build. The package name contains the kernel version and you should have one of these packages installed to match every kernel on your system. zfs-modules-devel-<verion>-<kernel>.arch.rpm - Binary rpm containing development header and module symbols needed for building additional kernel modules which are dependent on the zfs module stack. Expect minor interations on these changes as I validate they work properly on CHAOS, RHEL, Fedora, and SLES style distros.
2009-07-01 17:53:05 +00:00
ZFS_CONFIG=all
AC_ARG_WITH([config],
Refresh zfs-branch
2008-12-05 17:46:11 +00:00
AS_HELP_STRING([--with-config=CONFIG],
Add 'srpm' --with-config option for creation of spec files.
2009-11-24 22:13:25 +00:00
[Config file 'kernel|user|all|srpm']),
Build system and packaging (RPM support) (Part 1) An update to the build system to properly support all commonly used Makefile targets these include: make all # Build everything make install # Install everything make clean # Clean up build products make distclean # Clean up everything make dist # Create package tarball make srpm # Create package source RPM make rpm # Create package binary RPMs make tags # Create ctags and etags for everything Extra care was taken to ensure that the source RPMs are fully rebuildable against Fedora/RHEL/Chaos kernels. To build binary RPMs from the source RPM for your system simply run: rpmbuild --rebuild zfs-x.y.z-1.src.rpm This will produce two binary RPMs with correct 'requires' dependencies for your kernel. One will contain all zfs modules and support utilities, the other is a devel package for compiling additional kernel modules which are dependant on the zfs. zfs-x.y.z-1_<kernel version>.x86_64.rpm zfs-devel-x.y.2-1_<kernel version>.x86_64.rpm
2009-03-10 18:10:50 +00:00
[ZFS_CONFIG="$withval"])
Refresh zfs-branch
2008-12-05 17:46:11 +00:00
AC_MSG_CHECKING([zfs config])
Build system and packaging (RPM support) (Part 1) An update to the build system to properly support all commonly used Makefile targets these include: make all # Build everything make install # Install everything make clean # Clean up build products make distclean # Clean up everything make dist # Create package tarball make srpm # Create package source RPM make rpm # Create package binary RPMs make tags # Create ctags and etags for everything Extra care was taken to ensure that the source RPMs are fully rebuildable against Fedora/RHEL/Chaos kernels. To build binary RPMs from the source RPM for your system simply run: rpmbuild --rebuild zfs-x.y.z-1.src.rpm This will produce two binary RPMs with correct 'requires' dependencies for your kernel. One will contain all zfs modules and support utilities, the other is a devel package for compiling additional kernel modules which are dependant on the zfs. zfs-x.y.z-1_<kernel version>.x86_64.rpm zfs-devel-x.y.2-1_<kernel version>.x86_64.rpm
2009-03-10 18:10:50 +00:00
AC_MSG_RESULT([$ZFS_CONFIG]);
Distro friendly build system / packaging improvements. These changes bring the zfs-0.4.4 tree in to compliance with the spl-0.4.4 packaging changes. The bottom line is 2 source rpms and 4 binary rpms will now be generated when creating packages there will be: zfs-<version>.src.rpm - Fully rebuildable source rpm for libzfs and utils. zfs-modules-<version>.src.rpm - Fully rebuildable source rpm for kernel modules. zfs-<version>.<arch>.rpm - Binary rpm for libzfs and utils. The utils in this package are compatible with all zfs-module rpms of the same version. zfs-devel-<version>.<arch>.rpm - Binary rpm containing headers for building against libzfs libraries. zfs-modules-<verion>-<kernel>.arch.rpm - Binary rpm containing the kernel modules for a specific kernel build. The package name contains the kernel version and you should have one of these packages installed to match every kernel on your system. zfs-modules-devel-<verion>-<kernel>.arch.rpm - Binary rpm containing development header and module symbols needed for building additional kernel modules which are dependent on the zfs module stack. Expect minor interations on these changes as I validate they work properly on CHAOS, RHEL, Fedora, and SLES style distros.
2009-07-01 17:53:05 +00:00
AC_SUBST(ZFS_CONFIG)
Refresh zfs-branch
2008-12-05 17:46:11 +00:00
Build system and packaging (RPM support) (Part 1) An update to the build system to properly support all commonly used Makefile targets these include: make all # Build everything make install # Install everything make clean # Clean up build products make distclean # Clean up everything make dist # Create package tarball make srpm # Create package source RPM make rpm # Create package binary RPMs make tags # Create ctags and etags for everything Extra care was taken to ensure that the source RPMs are fully rebuildable against Fedora/RHEL/Chaos kernels. To build binary RPMs from the source RPM for your system simply run: rpmbuild --rebuild zfs-x.y.z-1.src.rpm This will produce two binary RPMs with correct 'requires' dependencies for your kernel. One will contain all zfs modules and support utilities, the other is a devel package for compiling additional kernel modules which are dependant on the zfs. zfs-x.y.z-1_<kernel version>.x86_64.rpm zfs-devel-x.y.2-1_<kernel version>.x86_64.rpm
2009-03-10 18:10:50 +00:00
case "$ZFS_CONFIG" in
Refresh zfs-branch
2008-12-05 17:46:11 +00:00
kernel) ZFS_AC_CONFIG_KERNEL ;;
Remove lustre config, we really shouldn't need this. A user space build -should- be able to contain all the needed APIs. If this is not the case we can reintroduce this.
2008-12-15 18:28:14 +00:00
user) ZFS_AC_CONFIG_USER ;;
all) ZFS_AC_CONFIG_KERNEL
ZFS_AC_CONFIG_USER ;;
Add 'srpm' --with-config option for creation of spec files.
2009-11-24 22:13:25 +00:00
srpm) ;;
Refresh zfs-branch
2008-12-05 17:46:11 +00:00
*)
AC_MSG_RESULT([Error!])
Build system and packaging (RPM support) (Part 1) An update to the build system to properly support all commonly used Makefile targets these include: make all # Build everything make install # Install everything make clean # Clean up build products make distclean # Clean up everything make dist # Create package tarball make srpm # Create package source RPM make rpm # Create package binary RPMs make tags # Create ctags and etags for everything Extra care was taken to ensure that the source RPMs are fully rebuildable against Fedora/RHEL/Chaos kernels. To build binary RPMs from the source RPM for your system simply run: rpmbuild --rebuild zfs-x.y.z-1.src.rpm This will produce two binary RPMs with correct 'requires' dependencies for your kernel. One will contain all zfs modules and support utilities, the other is a devel package for compiling additional kernel modules which are dependant on the zfs. zfs-x.y.z-1_<kernel version>.x86_64.rpm zfs-devel-x.y.2-1_<kernel version>.x86_64.rpm
2009-03-10 18:10:50 +00:00
AC_MSG_ERROR([Bad value "$ZFS_CONFIG" for --with-config,
Add 'srpm' --with-config option for creation of spec files.
2009-11-24 22:13:25 +00:00
user kernel|user|all|srpm]) ;;
Refresh zfs-branch
2008-12-05 17:46:11 +00:00
esac
Distro friendly build system / packaging improvements. These changes bring the zfs-0.4.4 tree in to compliance with the spl-0.4.4 packaging changes. The bottom line is 2 source rpms and 4 binary rpms will now be generated when creating packages there will be: zfs-<version>.src.rpm - Fully rebuildable source rpm for libzfs and utils. zfs-modules-<version>.src.rpm - Fully rebuildable source rpm for kernel modules. zfs-<version>.<arch>.rpm - Binary rpm for libzfs and utils. The utils in this package are compatible with all zfs-module rpms of the same version. zfs-devel-<version>.<arch>.rpm - Binary rpm containing headers for building against libzfs libraries. zfs-modules-<verion>-<kernel>.arch.rpm - Binary rpm containing the kernel modules for a specific kernel build. The package name contains the kernel version and you should have one of these packages installed to match every kernel on your system. zfs-modules-devel-<verion>-<kernel>.arch.rpm - Binary rpm containing development header and module symbols needed for building additional kernel modules which are dependent on the zfs module stack. Expect minor interations on these changes as I validate they work properly on CHAOS, RHEL, Fedora, and SLES style distros.
2009-07-01 17:53:05 +00:00
AM_CONDITIONAL([CONFIG_USER],
[test "$ZFS_CONFIG" = user] ||
[test "$ZFS_CONFIG" = all])
AM_CONDITIONAL([CONFIG_KERNEL],
[test "$ZFS_CONFIG" = kernel] ||
[test "$ZFS_CONFIG" = all])
Refresh zfs-branch
2008-12-05 17:46:11 +00:00
Distro friendly build system / packaging improvements. These changes bring the zfs-0.4.4 tree in to compliance with the spl-0.4.4 packaging changes. The bottom line is 2 source rpms and 4 binary rpms will now be generated when creating packages there will be: zfs-<version>.src.rpm - Fully rebuildable source rpm for libzfs and utils. zfs-modules-<version>.src.rpm - Fully rebuildable source rpm for kernel modules. zfs-<version>.<arch>.rpm - Binary rpm for libzfs and utils. The utils in this package are compatible with all zfs-module rpms of the same version. zfs-devel-<version>.<arch>.rpm - Binary rpm containing headers for building against libzfs libraries. zfs-modules-<verion>-<kernel>.arch.rpm - Binary rpm containing the kernel modules for a specific kernel build. The package name contains the kernel version and you should have one of these packages installed to match every kernel on your system. zfs-modules-devel-<verion>-<kernel>.arch.rpm - Binary rpm containing development header and module symbols needed for building additional kernel modules which are dependent on the zfs module stack. Expect minor interations on these changes as I validate they work properly on CHAOS, RHEL, Fedora, and SLES style distros.
2009-07-01 17:53:05 +00:00
ZFS_AC_CONFIG_SCRIPT
Refresh zfs-branch
2008-12-05 17:46:11 +00:00
])
Add Debian and Slackware style packaging via alien The long term fix for Debian and Slackware style packaging is to add native support for building these packages. Unfortunately, that is a large chunk of work I don't have time for right now. That said it would be nice to have at least basic packages for these distributions. As a quick short/medium term solution I've settled on using alien to convert the RPM packages to DEB or TGZ style packages. The build system has been updated with the following build targets which will first build RPM packages and then convert them as needed to the target package type: make rpm: Create .rpm packages make deb: Create .deb packages make tgz: Create .tgz packages make pkg: Create the right package type for your distribution The solution comes with lot of caveats and your mileage may vary. But basically the big limitations are that the resulting packages: 1) Will not have the correct dependency information. 2) Will not include the kernel version in the release. 3) Will not handle all differences between distributions. But the resulting packages should be easy to install and remove from your system and take care of running 'depmod -a' and such. As I said at the top this is not the right long term solution. If any of the upstream distribution maintainers want to jump in and help do this right for their distribution I'd love the help.
2010-07-27 23:45:36 +00:00
dnl #
dnl # Check for rpm+rpmbuild to build RPM packages. If these tools
dnl # are missing it is non-fatal but you will not be able to build
dnl # RPM packages and will be warned if you try too.
dnl #
AC_DEFUN([ZFS_AC_RPM], [
RPM=rpm
RPMBUILD=rpmbuild
AC_MSG_CHECKING([whether $RPM is available])
AS_IF([tmp=$($RPM --version 2>/dev/null)], [
RPM_VERSION=$(echo $tmp | $AWK '/RPM/ { print $[3] }')
HAVE_RPM=yes
AC_MSG_RESULT([$HAVE_RPM ($RPM_VERSION)])
],[
HAVE_RPM=no
AC_MSG_RESULT([$HAVE_RPM])
])
AC_MSG_CHECKING([whether $RPMBUILD is available])
AS_IF([tmp=$($RPMBUILD --version 2>/dev/null)], [
RPMBUILD_VERSION=$(echo $tmp | $AWK '/RPM/ { print $[3] }')
HAVE_RPMBUILD=yes
AC_MSG_RESULT([$HAVE_RPMBUILD ($RPMBUILD_VERSION)])
],[
HAVE_RPMBUILD=no
AC_MSG_RESULT([$HAVE_RPMBUILD])
])
AC_SUBST(HAVE_RPM)
AC_SUBST(RPM)
AC_SUBST(RPM_VERSION)
AC_SUBST(HAVE_RPMBUILD)
AC_SUBST(RPMBUILD)
AC_SUBST(RPMBUILD_VERSION)
])
dnl #
dnl # Check for dpkg+dpkg-buildpackage to build DEB packages. If these
dnl # tools are missing it is non-fatal but you will not be able to build
dnl # DEB packages and will be warned if you try too.
dnl #
AC_DEFUN([ZFS_AC_DPKG], [
DPKG=dpkg
DPKGBUILD=dpkg-buildpackage
AC_MSG_CHECKING([whether $DPKG is available])
AS_IF([tmp=$($DPKG --version 2>/dev/null)], [
DPKG_VERSION=$(echo $tmp | $AWK '/Debian/ { print $[7] }')
HAVE_DPKG=yes
AC_MSG_RESULT([$HAVE_DPKG ($DPKG_VERSION)])
],[
HAVE_DPKG=no
AC_MSG_RESULT([$HAVE_DPKG])
])
AC_MSG_CHECKING([whether $DPKGBUILD is available])
AS_IF([tmp=$($DPKGBUILD --version 2>/dev/null)], [
DPKGBUILD_VERSION=$(echo $tmp | \
$AWK '/Debian/ { print $[4] }' | cut -f-4 -d'.')
HAVE_DPKGBUILD=yes
AC_MSG_RESULT([$HAVE_DPKGBUILD ($DPKGBUILD_VERSION)])
],[
HAVE_DPKGBUILD=no
AC_MSG_RESULT([$HAVE_DPKGBUILD])
])
AC_SUBST(HAVE_DPKG)
AC_SUBST(DPKG)
AC_SUBST(DPKG_VERSION)
AC_SUBST(HAVE_DPKGBUILD)
AC_SUBST(DPKGBUILD)
AC_SUBST(DPKGBUILD_VERSION)
])
dnl #
dnl # Until native packaging for various different packing systems
dnl # can be added the least we can do is attempt to use alien to
dnl # convert the RPM packages to the needed package type. This is
dnl # a hack but so far it has worked reasonable well.
dnl #
AC_DEFUN([ZFS_AC_ALIEN], [
ALIEN=alien
AC_MSG_CHECKING([whether $ALIEN is available])
AS_IF([tmp=$($ALIEN --version 2>/dev/null)], [
ALIEN_VERSION=$(echo $tmp | $AWK '{ print $[3] }')
HAVE_ALIEN=yes
AC_MSG_RESULT([$HAVE_ALIEN ($ALIEN_VERSION)])
],[
HAVE_ALIEN=no
AC_MSG_RESULT([$HAVE_ALIEN])
])
AC_SUBST(HAVE_ALIEN)
AC_SUBST(ALIEN)
AC_SUBST(ALIEN_VERSION)
])
dnl #
dnl # Using the VENDOR tag from config.guess set the default
dnl # package type for 'make pkg': (rpm | deb | tgz)
dnl #
AC_DEFUN([ZFS_AC_DEFAULT_PACKAGE], [
VENDOR=$(echo $ac_build_alias | cut -f2 -d'-')
AC_MSG_CHECKING([default package type])
case "$VENDOR" in
fedora) DEFAULT_PACKAGE=rpm ;;
redhat) DEFAULT_PACKAGE=rpm ;;
sles) DEFAULT_PACKAGE=rpm ;;
ubuntu) DEFAULT_PACKAGE=deb ;;
debian) DEFAULT_PACKAGE=deb ;;
slackware) DEFAULT_PACKAGE=tgz ;;
*) DEFAULT_PACKAGE=rpm ;;
esac
AC_MSG_RESULT([$DEFAULT_PACKAGE])
AC_SUBST(DEFAULT_PACKAGE)
])
dnl #
dnl # Default ZFS package configuration
dnl #
AC_DEFUN([ZFS_AC_PACKAGE], [
ZFS_AC_RPM
ZFS_AC_DPKG
ZFS_AC_ALIEN
ZFS_AC_DEFAULT_PACKAGE
])