summaryrefslogtreecommitdiffstats
path: root/Makefile.am
Commit message (Collapse)AuthorAgeFilesLines
* Support custom build directoriesBrian Behlendorf2010-09-051-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Remove spl-x.y.z.zip creation in 'make dist'Brian Behlendorf2010-09-021-1/+1
| | | | | Do no create a spl-x.y.z.zip file as part of 'make dist'. Simply create the standard spl-x.y.z.tar.gz file.
* Add uninstall Makefile targetsBrian Behlendorf2010-07-281-1/+1
| | | | | | | | Extend the Makefiles with an uninstall target to cleanly remove a package which was installed with 'make install'. Additionally, ensure a 'depmod -a' is run as part of the install to update the module dependency information.
* Add Debian and Slackware style packaging via alienBrian Behlendorf2010-07-271-20/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 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.
* Allow spl_config.h to be included by dependant packages (updated)Brian Behlendorf2010-03-221-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | We need dependent packages to be able to include spl_config.h to build properly. This was partially solved in commit 0cbaeb1 by using AH_BOTTOM to #undef common #defines (PACKAGE, VERSION, etc) which autoconf always adds and cannot be easily removed. This solution works as long as the spl_config.h is included before your projects config.h. That turns out to be easier said than done. In particular, this is a problem when your package includes its config.h using the -include gcc option which ensures the first thing included is your config.h. To handle all cases cleanly I have removed the AH_BOTTOM hack and replaced it with an AC_CONFIG_HEADERS command. This command runs immediately after spl_config.h is written and with a little awk-foo it strips the offending #defines from the file. This eliminates the problem entirely and makes header safe for inclusion. Also in this change I have removed the few places in the code where spl_config.h is included. It is now added to the gcc compile line to ensure the config results are always available. Finally, I have also disabled the verbose kernel builds. If you want them back you can always build with 'make V=1'. Since things are working now they don't need to be on by default.
* Ensure *.order and *.markers build products are removed by distclean rule.Brian Behlendorf2009-11-201-1/+2
|
* Simplify rpm build rules, added config/rpm.am.Brian Behlendorf2009-07-011-25/+30
| | | | Distro friendly changes such that the kernel modules are packaged seperately.
* Add spl.release to spl-devel to simply dependent package version check.Brian Behlendorf2009-06-291-0/+1
|
* Install spl-devel products in /usr/src/spl-SPL_VERSION/LINUX_VERSION/Brian Behlendorf2009-06-261-2/+2
| | | | Remove the spl symlink, it's just confusing
* Packaging improvements for RHEL and SLES (part 2)Brian Behlendorf2009-06-161-2/+2
| | | | | | | - Allow checking for exported symbols in both Module.symvers and Module.symvers. My stock SLES kernel ships an objects directory with Module.symvers, yet produces a Module.symvers in the local build directory.
* Packaging improvements for RHEL and SLESBrian Behlendorf2009-06-161-3/+6
| | | | | | | | | | | | | | | - Properly honor --prefix in build system and rpm spec file. - Add '--define require_kdir' to spec file to support building rpms against kernel sources installed in non-default locations. - Add '--define require_kobj' to spec file to support building rpms against kernel object installed in non-default locations. - Stop suppressing errors in autogen.sh script. - Improved logic to detect missing kernel objects when they are not located with the source. This is the common case for SLES as well as in-tree chaos kernel builds and is done to simply support for multiple arches. - Moved spl-devel build products to /usr/src/spl-<version>, a spl symlink is created to reference the last installed version.
* Allow spl_config.h to be included by dependant packagesBrian Behlendorf2009-03-171-1/+2
| | | | | | | | | | | | | | | | We need dependent packages to be able to include spl_config.h so they can leverage the configure checks the SPL has done. This is important because several of the spl headers need the results of these checks to work properly. Unfortunately, the autoheader build product is always private to a particular build and defined certain common things. (PACKAGE, VERSION, etc). This prevents other packages which also use autoheader from being include because the definitions conflict. To avoid this problem the SPL build system leverage AH_BOTTOM to include a spl_unconfig.h at the botton of the autoheader build product. This custom include undefs all known shared symbols to prevent the confict. This does however mean that those definition are also not availble to the SPL package either. The SPL package therefore uses the equivilant SPL_META_* definitions.
* Build system cleanupBrian Behlendorf2009-03-111-3/+3
| | | | | | 1) Undefine non-unique entries in spl_config.h 2) Minor Makefile cleanup 3) Don't use includedir for proper kernel header install
* Build system and packaging (RPM support)Brian Behlendorf2009-03-091-6/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 spl-x.y.z-1.src.rpm This will produce two binary RPMs with correct 'requires' dependencies for your kernel. One will contain all spl modules and support utilities, the other is a devel package for compiling additional kernel modules which are dependant on the spl. spl-x.y.z-1_<kernel version>.x86_64.rpm spl-devel-x.y.2-1_<kernel version>.x86_64.rpm
* Rename modules to module and update referencesBrian Behlendorf2009-01-151-1/+1
|
* OK, everything builds now. My initial intent was to place all ofbehlendo2008-02-271-1/+2
| | | | | | | | | | | | the directories at the top level but that proved troublesome. The kernel buildsystem and autoconf were conflicting too much. To resolve the issue I moved the kernel bits in to a modules directory which can then only use the kernel build system. We just pass along the likely make targets to the kernel build system. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@11 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
* Initial commit. All spl source written up to this point wrappedbehlendo2008-02-261-0/+9
in an initial reasonable autoconf style build system. This does not yet build but the configure system does appear to work properly and integrate with the kernel. Hopefully the next commit gets us back to a buildable version we can run the test suite against. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@1 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c