nixo
/
gri3-wm
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
gri3-wm/configure.ac

200 lines
7.7 KiB
Plaintext
Raw Normal View History

Switch to autotools (GNU build system) This commit probably comes as a surprise to some, given that one of i3’s explicitly stated goals used to be “Do not use programs such as autoconf/automake for configuration and creating unreadable/broken makefiles”. I phrased this goal over 7 years ago, based largely on a grudge that I inherited, which — as I’ve realized in the meantime — was largely held against FOSS in general, and not actually nuanced criticism of autotools. In the meantime, I have come to realize that the knee-jerk reaction of “I could do this better!” (i.e. writing our own build system in this particular case) is usually misguided, and nowadays I strongly suggest trying hard to fix the existing system for the benefit of all existing and future users. Further, I recently got to experience the other side of the coin, as I packaged a new version of FreeRADIUS for Debian, which at the time of writing used autoconf in combination with boilermake, a custom make-based build system that only FreeRADIUS uses. Understanding the build system enough to fix issues and enable parallel compilation took me an entire day. That time is time which potentially every downstream maintainer needs to invest, and the resulting knowledge cannot be applied to any other project. Hence, I believe it’s a good idea switch i3 to autotools. Yes, it might be that particular features were easier to implement/understand in our custom Makefiles, and there might be individuals who have an easier time reading through our custom Makefiles than learning autotools. All of these considerations are outweighed by the benefits we get from using the same build system as literally thousands of other FOSS software packages. Aside from these somewhat philosophical considerations, there’s also practical improvements which this change brings us. See the “changes” section below. ┌──────────────────────────────────────────────────────────────────────────────┐ │ new workflow │ └──────────────────────────────────────────────────────────────────────────────┘ You can now build i3 like you build any other software package which uses autotools. Here’s a memory refresher: autoreconf -fi mkdir -p build && cd build ../configure make -j8 (The autoreconf -fi step is unnecessary if you are building from a release tarball, but shouldn’t hurt either.) ┌──────────────────────────────────────────────────────────────────────────────┐ │ recommended reading │ └──────────────────────────────────────────────────────────────────────────────┘ I very much recommend reading “A Practitioner's Guide to GNU Autoconf, Automake, and Libtool” by John Calcote (https://www.nostarch.com/autotools.htm). That book is from 2010 and, AFAICT, is the most up to date comprehensive description of autotools. Do not read older documentation. In particular, if a document you’re reading mentions configure.in (deprecated filename) or recursive make (now considered harmful), it’s likely outdated. ┌──────────────────────────────────────────────────────────────────────────────┐ │ changes │ └──────────────────────────────────────────────────────────────────────────────┘ This commit implements the following new functionality/changes in behavior: • We use the AX_ENABLE_BUILDDIR macro to enforce builds happening in a separate directory. This is a prerequisite for the AX_EXTEND_SRCDIR macro and building in a separate directory is common practice anyway. In case this causes any trouble when packaging i3 for your distribution, please let me know. • “make check” runs the i3 testsuite. You can still use ./testcases/complete-run.pl to get the interactive progress output. • “make distcheck” (runs testsuite on “make dist” result, tiny bit quicker feedback cycle than waiting for the travis build to catch the issue). • “make uninstall” (occasionally requested by users who compile from source) • “make” will build manpages/docs by default if the tools are installed. Conversely, manpages/docs are not tried to be built for users who don’t want to install all these dependencies to get started hacking on i3. • non-release builds will enable address sanitizer by default. Use the --disable-sanitizers configure option to turn off all sanitizers, and see --help for available sanitizers. • Support for pre-compiled headers (PCH) has been dropped for now in the interest of simplicitly. Maybe we can re-add it later. • coverage reports are now generated using “make check-code-coverage”, which requires specifying --enable-code-coverage when calling configure. ┌──────────────────────────────────────────────────────────────────────────────┐ │ build system feature parity/testing │ └──────────────────────────────────────────────────────────────────────────────┘ In addition to what’s described above, I tested the following features: • “make install” installs the same files (plus documentation and manpages) cd i3-old && make install PREFIX=/tmp/inst/old cd i3-new && ./configure --prefix=/tmp/inst/new cd /tmp/inst (cd old && for f in $(find); do [ -e "../new/$f" ] || echo "$f missing"; done) • make dist generates a tarball which includes the same files cd i3-old && make dist cd i3-new/x86_64-pc-linux-gnu && make dist colordiff -u <(tar tf i3-old/i3-4.12.tar.bz2 | sort) \ <(tar tf i3-new/x86_64-pc-linux-gnu/i3-4.12.tar.gz | sort) There are some expected differences: • Some files have been renamed (e.g. the new etc/ and share/ subdirectories) • Some files will now be generated at build-time, so only their corresponding .in file is shipped (e.g. testcases/complete-run.pl) • The generated parser files are shipped in the dist tarball (they only depend on the parser-specs/* files, not on the target system) • autotools infrastructure is shipped (e.g. “configure”, “missing”, etc.) • DLOG and ELOG statements still produce the same file name in logfiles • Listing source code in gdb still works. • gdb backtraces contain the i3-<version> path component • release.sh still works • version embedding 1. git checkout shows “4.12-136-gf720023 (2016-10-10, branch "autotools")” 2. tarball of a git version shows “4.12-non-git” 3. release tarball shows 4.13 • debug mode is enabled by default for non-release builds • enabling verbose builds via V=1 ┌──────────────────────────────────────────────────────────────────────────────┐ │ speed │ └──────────────────────────────────────────────────────────────────────────────┘ There is no noticeable difference in compilation speed itself (of binaries, documentation and manpages): i3-old $ time make all docs mans -j8 make all docs mans -j8 28.92s user 2.15s system 640% cpu 4.852 total i3-new $ time make -j8 make -j8 27.08s user 1.92s system 620% cpu 4.669 total In terms of one-time costs: configuring the build system (../configure) takes about 2.7s on my machine, generating the build system (autoreconf -fi) takes about 3.1s on my machine. ┌──────────────────────────────────────────────────────────────────────────────┐ │ m4 macros │ └──────────────────────────────────────────────────────────────────────────────┘ All files in m4/ have been copied from the autoconf-archive package in version b6aeb1988f4b6c78bf39d97b6c4f6e1d594d59b9 and should be updated whenever they change. This commit has been tested with autoconf 2.69 and automake 1.15.
2016-10-07 13:48:26 +02:00
# -*- Autoconf -*-
# Run autoreconf -fi to generate a configure script from this file.
AC_PREREQ([2.69])
release i3 4.17.1
2019-08-30 23:06:47 +02:00
AC_INIT([i3], [4.17.1], [https://github.com/i3/i3/issues])
Switch to autotools (GNU build system) This commit probably comes as a surprise to some, given that one of i3’s explicitly stated goals used to be “Do not use programs such as autoconf/automake for configuration and creating unreadable/broken makefiles”. I phrased this goal over 7 years ago, based largely on a grudge that I inherited, which — as I’ve realized in the meantime — was largely held against FOSS in general, and not actually nuanced criticism of autotools. In the meantime, I have come to realize that the knee-jerk reaction of “I could do this better!” (i.e. writing our own build system in this particular case) is usually misguided, and nowadays I strongly suggest trying hard to fix the existing system for the benefit of all existing and future users. Further, I recently got to experience the other side of the coin, as I packaged a new version of FreeRADIUS for Debian, which at the time of writing used autoconf in combination with boilermake, a custom make-based build system that only FreeRADIUS uses. Understanding the build system enough to fix issues and enable parallel compilation took me an entire day. That time is time which potentially every downstream maintainer needs to invest, and the resulting knowledge cannot be applied to any other project. Hence, I believe it’s a good idea switch i3 to autotools. Yes, it might be that particular features were easier to implement/understand in our custom Makefiles, and there might be individuals who have an easier time reading through our custom Makefiles than learning autotools. All of these considerations are outweighed by the benefits we get from using the same build system as literally thousands of other FOSS software packages. Aside from these somewhat philosophical considerations, there’s also practical improvements which this change brings us. See the “changes” section below. ┌──────────────────────────────────────────────────────────────────────────────┐ │ new workflow │ └──────────────────────────────────────────────────────────────────────────────┘ You can now build i3 like you build any other software package which uses autotools. Here’s a memory refresher: autoreconf -fi mkdir -p build && cd build ../configure make -j8 (The autoreconf -fi step is unnecessary if you are building from a release tarball, but shouldn’t hurt either.) ┌──────────────────────────────────────────────────────────────────────────────┐ │ recommended reading │ └──────────────────────────────────────────────────────────────────────────────┘ I very much recommend reading “A Practitioner's Guide to GNU Autoconf, Automake, and Libtool” by John Calcote (https://www.nostarch.com/autotools.htm). That book is from 2010 and, AFAICT, is the most up to date comprehensive description of autotools. Do not read older documentation. In particular, if a document you’re reading mentions configure.in (deprecated filename) or recursive make (now considered harmful), it’s likely outdated. ┌──────────────────────────────────────────────────────────────────────────────┐ │ changes │ └──────────────────────────────────────────────────────────────────────────────┘ This commit implements the following new functionality/changes in behavior: • We use the AX_ENABLE_BUILDDIR macro to enforce builds happening in a separate directory. This is a prerequisite for the AX_EXTEND_SRCDIR macro and building in a separate directory is common practice anyway. In case this causes any trouble when packaging i3 for your distribution, please let me know. • “make check” runs the i3 testsuite. You can still use ./testcases/complete-run.pl to get the interactive progress output. • “make distcheck” (runs testsuite on “make dist” result, tiny bit quicker feedback cycle than waiting for the travis build to catch the issue). • “make uninstall” (occasionally requested by users who compile from source) • “make” will build manpages/docs by default if the tools are installed. Conversely, manpages/docs are not tried to be built for users who don’t want to install all these dependencies to get started hacking on i3. • non-release builds will enable address sanitizer by default. Use the --disable-sanitizers configure option to turn off all sanitizers, and see --help for available sanitizers. • Support for pre-compiled headers (PCH) has been dropped for now in the interest of simplicitly. Maybe we can re-add it later. • coverage reports are now generated using “make check-code-coverage”, which requires specifying --enable-code-coverage when calling configure. ┌──────────────────────────────────────────────────────────────────────────────┐ │ build system feature parity/testing │ └──────────────────────────────────────────────────────────────────────────────┘ In addition to what’s described above, I tested the following features: • “make install” installs the same files (plus documentation and manpages) cd i3-old && make install PREFIX=/tmp/inst/old cd i3-new && ./configure --prefix=/tmp/inst/new cd /tmp/inst (cd old && for f in $(find); do [ -e "../new/$f" ] || echo "$f missing"; done) • make dist generates a tarball which includes the same files cd i3-old && make dist cd i3-new/x86_64-pc-linux-gnu && make dist colordiff -u <(tar tf i3-old/i3-4.12.tar.bz2 | sort) \ <(tar tf i3-new/x86_64-pc-linux-gnu/i3-4.12.tar.gz | sort) There are some expected differences: • Some files have been renamed (e.g. the new etc/ and share/ subdirectories) • Some files will now be generated at build-time, so only their corresponding .in file is shipped (e.g. testcases/complete-run.pl) • The generated parser files are shipped in the dist tarball (they only depend on the parser-specs/* files, not on the target system) • autotools infrastructure is shipped (e.g. “configure”, “missing”, etc.) • DLOG and ELOG statements still produce the same file name in logfiles • Listing source code in gdb still works. • gdb backtraces contain the i3-<version> path component • release.sh still works • version embedding 1. git checkout shows “4.12-136-gf720023 (2016-10-10, branch "autotools")” 2. tarball of a git version shows “4.12-non-git” 3. release tarball shows 4.13 • debug mode is enabled by default for non-release builds • enabling verbose builds via V=1 ┌──────────────────────────────────────────────────────────────────────────────┐ │ speed │ └──────────────────────────────────────────────────────────────────────────────┘ There is no noticeable difference in compilation speed itself (of binaries, documentation and manpages): i3-old $ time make all docs mans -j8 make all docs mans -j8 28.92s user 2.15s system 640% cpu 4.852 total i3-new $ time make -j8 make -j8 27.08s user 1.92s system 620% cpu 4.669 total In terms of one-time costs: configuring the build system (../configure) takes about 2.7s on my machine, generating the build system (autoreconf -fi) takes about 3.1s on my machine. ┌──────────────────────────────────────────────────────────────────────────────┐ │ m4 macros │ └──────────────────────────────────────────────────────────────────────────────┘ All files in m4/ have been copied from the autoconf-archive package in version b6aeb1988f4b6c78bf39d97b6c4f6e1d594d59b9 and should be updated whenever they change. This commit has been tested with autoconf 2.69 and automake 1.15.
2016-10-07 13:48:26 +02:00
# For AX_EXTEND_SRCDIR
AX_ENABLE_BUILDDIR
AM_INIT_AUTOMAKE([foreign subdir-objects -Wall no-dist-gzip dist-bzip2])
# Default to silent rules, use V=1 to get verbose compilation output.
AM_SILENT_RULES([yes])
# Make it possible to disable maintainer mode to disable re-generation of build
# system files.
AM_MAINTAINER_MODE([enable])
AC_CONFIG_SRCDIR([libi3/ipc_recv_message.c])
AC_CONFIG_HEADERS([config.h])
AC_CONFIG_MACRO_DIR([m4])
configure.ac: verify macros in m4/ are being replaced (Thanks sur5r) (#2571) See the comment for more details, and see the motivating blog post: https://blogs.noname-ev.de/sur5r/index.php?/archives/7-Another-instance-of-AC_DEFINE-being-undefined.html
2016-11-19 23:45:22 +01:00
dnl Verify macros defined in m4/ such as AX_SANITIZERS are not present in the
dnl output, i.e. are replaced as expected. This line results in a better error
dnl message when using aclocal < 1.13 (which does not understand
dnl AC_CONFIG_MACRO_DIR) without passing the -I m4 parameter.
m4_pattern_forbid([AX_SANITIZERS])
Switch to autotools (GNU build system) This commit probably comes as a surprise to some, given that one of i3’s explicitly stated goals used to be “Do not use programs such as autoconf/automake for configuration and creating unreadable/broken makefiles”. I phrased this goal over 7 years ago, based largely on a grudge that I inherited, which — as I’ve realized in the meantime — was largely held against FOSS in general, and not actually nuanced criticism of autotools. In the meantime, I have come to realize that the knee-jerk reaction of “I could do this better!” (i.e. writing our own build system in this particular case) is usually misguided, and nowadays I strongly suggest trying hard to fix the existing system for the benefit of all existing and future users. Further, I recently got to experience the other side of the coin, as I packaged a new version of FreeRADIUS for Debian, which at the time of writing used autoconf in combination with boilermake, a custom make-based build system that only FreeRADIUS uses. Understanding the build system enough to fix issues and enable parallel compilation took me an entire day. That time is time which potentially every downstream maintainer needs to invest, and the resulting knowledge cannot be applied to any other project. Hence, I believe it’s a good idea switch i3 to autotools. Yes, it might be that particular features were easier to implement/understand in our custom Makefiles, and there might be individuals who have an easier time reading through our custom Makefiles than learning autotools. All of these considerations are outweighed by the benefits we get from using the same build system as literally thousands of other FOSS software packages. Aside from these somewhat philosophical considerations, there’s also practical improvements which this change brings us. See the “changes” section below. ┌──────────────────────────────────────────────────────────────────────────────┐ │ new workflow │ └──────────────────────────────────────────────────────────────────────────────┘ You can now build i3 like you build any other software package which uses autotools. Here’s a memory refresher: autoreconf -fi mkdir -p build && cd build ../configure make -j8 (The autoreconf -fi step is unnecessary if you are building from a release tarball, but shouldn’t hurt either.) ┌──────────────────────────────────────────────────────────────────────────────┐ │ recommended reading │ └──────────────────────────────────────────────────────────────────────────────┘ I very much recommend reading “A Practitioner's Guide to GNU Autoconf, Automake, and Libtool” by John Calcote (https://www.nostarch.com/autotools.htm). That book is from 2010 and, AFAICT, is the most up to date comprehensive description of autotools. Do not read older documentation. In particular, if a document you’re reading mentions configure.in (deprecated filename) or recursive make (now considered harmful), it’s likely outdated. ┌──────────────────────────────────────────────────────────────────────────────┐ │ changes │ └──────────────────────────────────────────────────────────────────────────────┘ This commit implements the following new functionality/changes in behavior: • We use the AX_ENABLE_BUILDDIR macro to enforce builds happening in a separate directory. This is a prerequisite for the AX_EXTEND_SRCDIR macro and building in a separate directory is common practice anyway. In case this causes any trouble when packaging i3 for your distribution, please let me know. • “make check” runs the i3 testsuite. You can still use ./testcases/complete-run.pl to get the interactive progress output. • “make distcheck” (runs testsuite on “make dist” result, tiny bit quicker feedback cycle than waiting for the travis build to catch the issue). • “make uninstall” (occasionally requested by users who compile from source) • “make” will build manpages/docs by default if the tools are installed. Conversely, manpages/docs are not tried to be built for users who don’t want to install all these dependencies to get started hacking on i3. • non-release builds will enable address sanitizer by default. Use the --disable-sanitizers configure option to turn off all sanitizers, and see --help for available sanitizers. • Support for pre-compiled headers (PCH) has been dropped for now in the interest of simplicitly. Maybe we can re-add it later. • coverage reports are now generated using “make check-code-coverage”, which requires specifying --enable-code-coverage when calling configure. ┌──────────────────────────────────────────────────────────────────────────────┐ │ build system feature parity/testing │ └──────────────────────────────────────────────────────────────────────────────┘ In addition to what’s described above, I tested the following features: • “make install” installs the same files (plus documentation and manpages) cd i3-old && make install PREFIX=/tmp/inst/old cd i3-new && ./configure --prefix=/tmp/inst/new cd /tmp/inst (cd old && for f in $(find); do [ -e "../new/$f" ] || echo "$f missing"; done) • make dist generates a tarball which includes the same files cd i3-old && make dist cd i3-new/x86_64-pc-linux-gnu && make dist colordiff -u <(tar tf i3-old/i3-4.12.tar.bz2 | sort) \ <(tar tf i3-new/x86_64-pc-linux-gnu/i3-4.12.tar.gz | sort) There are some expected differences: • Some files have been renamed (e.g. the new etc/ and share/ subdirectories) • Some files will now be generated at build-time, so only their corresponding .in file is shipped (e.g. testcases/complete-run.pl) • The generated parser files are shipped in the dist tarball (they only depend on the parser-specs/* files, not on the target system) • autotools infrastructure is shipped (e.g. “configure”, “missing”, etc.) • DLOG and ELOG statements still produce the same file name in logfiles • Listing source code in gdb still works. • gdb backtraces contain the i3-<version> path component • release.sh still works • version embedding 1. git checkout shows “4.12-136-gf720023 (2016-10-10, branch "autotools")” 2. tarball of a git version shows “4.12-non-git” 3. release tarball shows 4.13 • debug mode is enabled by default for non-release builds • enabling verbose builds via V=1 ┌──────────────────────────────────────────────────────────────────────────────┐ │ speed │ └──────────────────────────────────────────────────────────────────────────────┘ There is no noticeable difference in compilation speed itself (of binaries, documentation and manpages): i3-old $ time make all docs mans -j8 make all docs mans -j8 28.92s user 2.15s system 640% cpu 4.852 total i3-new $ time make -j8 make -j8 27.08s user 1.92s system 620% cpu 4.669 total In terms of one-time costs: configuring the build system (../configure) takes about 2.7s on my machine, generating the build system (autoreconf -fi) takes about 3.1s on my machine. ┌──────────────────────────────────────────────────────────────────────────────┐ │ m4 macros │ └──────────────────────────────────────────────────────────────────────────────┘ All files in m4/ have been copied from the autoconf-archive package in version b6aeb1988f4b6c78bf39d97b6c4f6e1d594d59b9 and should be updated whenever they change. This commit has been tested with autoconf 2.69 and automake 1.15.
2016-10-07 13:48:26 +02:00
# Verify we are using GNU make because we use '%'-style pattern rules in
# Makefile.am, which are a GNU make extension. Pull requests to replace
# '%'-style pattern rules with a more portable alternative are welcome.
AX_CHECK_GNU_MAKE
AS_VAR_IF([_cv_gnu_make_command], [""], [AC_MSG_ERROR([the i3 Makefile.am requires GNU make])])
AX_EXTEND_SRCDIR
AS_IF([test -d ${srcdir}/.git],
[
properly detect version when building out of tree
2017-01-10 01:47:16 +01:00
VERSION="$(git -C ${srcdir} describe --tags --abbrev=0)"
Use git plumbing commands to get the I3_VERSION Fixes #3656
2019-03-22 14:06:23 +01:00
I3_VERSION="$(git -C ${srcdir} describe --tags --always) ($(git -C ${srcdir} rev-list --format=%cd --date=short -n1 $(git rev-parse HEAD) | tail -n1), branch \\\"$(git -C ${srcdir} describe --tags --always --all | sed s:heads/::)\\\")"
Switch to autotools (GNU build system) This commit probably comes as a surprise to some, given that one of i3’s explicitly stated goals used to be “Do not use programs such as autoconf/automake for configuration and creating unreadable/broken makefiles”. I phrased this goal over 7 years ago, based largely on a grudge that I inherited, which — as I’ve realized in the meantime — was largely held against FOSS in general, and not actually nuanced criticism of autotools. In the meantime, I have come to realize that the knee-jerk reaction of “I could do this better!” (i.e. writing our own build system in this particular case) is usually misguided, and nowadays I strongly suggest trying hard to fix the existing system for the benefit of all existing and future users. Further, I recently got to experience the other side of the coin, as I packaged a new version of FreeRADIUS for Debian, which at the time of writing used autoconf in combination with boilermake, a custom make-based build system that only FreeRADIUS uses. Understanding the build system enough to fix issues and enable parallel compilation took me an entire day. That time is time which potentially every downstream maintainer needs to invest, and the resulting knowledge cannot be applied to any other project. Hence, I believe it’s a good idea switch i3 to autotools. Yes, it might be that particular features were easier to implement/understand in our custom Makefiles, and there might be individuals who have an easier time reading through our custom Makefiles than learning autotools. All of these considerations are outweighed by the benefits we get from using the same build system as literally thousands of other FOSS software packages. Aside from these somewhat philosophical considerations, there’s also practical improvements which this change brings us. See the “changes” section below. ┌──────────────────────────────────────────────────────────────────────────────┐ │ new workflow │ └──────────────────────────────────────────────────────────────────────────────┘ You can now build i3 like you build any other software package which uses autotools. Here’s a memory refresher: autoreconf -fi mkdir -p build && cd build ../configure make -j8 (The autoreconf -fi step is unnecessary if you are building from a release tarball, but shouldn’t hurt either.) ┌──────────────────────────────────────────────────────────────────────────────┐ │ recommended reading │ └──────────────────────────────────────────────────────────────────────────────┘ I very much recommend reading “A Practitioner's Guide to GNU Autoconf, Automake, and Libtool” by John Calcote (https://www.nostarch.com/autotools.htm). That book is from 2010 and, AFAICT, is the most up to date comprehensive description of autotools. Do not read older documentation. In particular, if a document you’re reading mentions configure.in (deprecated filename) or recursive make (now considered harmful), it’s likely outdated. ┌──────────────────────────────────────────────────────────────────────────────┐ │ changes │ └──────────────────────────────────────────────────────────────────────────────┘ This commit implements the following new functionality/changes in behavior: • We use the AX_ENABLE_BUILDDIR macro to enforce builds happening in a separate directory. This is a prerequisite for the AX_EXTEND_SRCDIR macro and building in a separate directory is common practice anyway. In case this causes any trouble when packaging i3 for your distribution, please let me know. • “make check” runs the i3 testsuite. You can still use ./testcases/complete-run.pl to get the interactive progress output. • “make distcheck” (runs testsuite on “make dist” result, tiny bit quicker feedback cycle than waiting for the travis build to catch the issue). • “make uninstall” (occasionally requested by users who compile from source) • “make” will build manpages/docs by default if the tools are installed. Conversely, manpages/docs are not tried to be built for users who don’t want to install all these dependencies to get started hacking on i3. • non-release builds will enable address sanitizer by default. Use the --disable-sanitizers configure option to turn off all sanitizers, and see --help for available sanitizers. • Support for pre-compiled headers (PCH) has been dropped for now in the interest of simplicitly. Maybe we can re-add it later. • coverage reports are now generated using “make check-code-coverage”, which requires specifying --enable-code-coverage when calling configure. ┌──────────────────────────────────────────────────────────────────────────────┐ │ build system feature parity/testing │ └──────────────────────────────────────────────────────────────────────────────┘ In addition to what’s described above, I tested the following features: • “make install” installs the same files (plus documentation and manpages) cd i3-old && make install PREFIX=/tmp/inst/old cd i3-new && ./configure --prefix=/tmp/inst/new cd /tmp/inst (cd old && for f in $(find); do [ -e "../new/$f" ] || echo "$f missing"; done) • make dist generates a tarball which includes the same files cd i3-old && make dist cd i3-new/x86_64-pc-linux-gnu && make dist colordiff -u <(tar tf i3-old/i3-4.12.tar.bz2 | sort) \ <(tar tf i3-new/x86_64-pc-linux-gnu/i3-4.12.tar.gz | sort) There are some expected differences: • Some files have been renamed (e.g. the new etc/ and share/ subdirectories) • Some files will now be generated at build-time, so only their corresponding .in file is shipped (e.g. testcases/complete-run.pl) • The generated parser files are shipped in the dist tarball (they only depend on the parser-specs/* files, not on the target system) • autotools infrastructure is shipped (e.g. “configure”, “missing”, etc.) • DLOG and ELOG statements still produce the same file name in logfiles • Listing source code in gdb still works. • gdb backtraces contain the i3-<version> path component • release.sh still works • version embedding 1. git checkout shows “4.12-136-gf720023 (2016-10-10, branch "autotools")” 2. tarball of a git version shows “4.12-non-git” 3. release tarball shows 4.13 • debug mode is enabled by default for non-release builds • enabling verbose builds via V=1 ┌──────────────────────────────────────────────────────────────────────────────┐ │ speed │ └──────────────────────────────────────────────────────────────────────────────┘ There is no noticeable difference in compilation speed itself (of binaries, documentation and manpages): i3-old $ time make all docs mans -j8 make all docs mans -j8 28.92s user 2.15s system 640% cpu 4.852 total i3-new $ time make -j8 make -j8 27.08s user 1.92s system 620% cpu 4.669 total In terms of one-time costs: configuring the build system (../configure) takes about 2.7s on my machine, generating the build system (autoreconf -fi) takes about 3.1s on my machine. ┌──────────────────────────────────────────────────────────────────────────────┐ │ m4 macros │ └──────────────────────────────────────────────────────────────────────────────┘ All files in m4/ have been copied from the autoconf-archive package in version b6aeb1988f4b6c78bf39d97b6c4f6e1d594d59b9 and should be updated whenever they change. This commit has been tested with autoconf 2.69 and automake 1.15.
2016-10-07 13:48:26 +02:00
# Mirrors what libi3/is_debug_build.c does:
is_release=$(test $(echo "${I3_VERSION}" | cut -d '(' -f 1 | wc -m) -lt 10 && echo yes || echo no)
],
[
VERSION="$(cut -d '-' -f 1 ${srcdir}/I3_VERSION | cut -d ' ' -f 1)"
Bugfix: escape I3_VERSION when read from file (#2517) I3_VERSION is used as string literal in config.h, i.e.: #define I3_VERSION … Where “…” is replaced with the contents of I3_VERSION. For our travis builds, we persist the version number to I3_VERSION, i.e.: $ cat I3_VERSION 4.12-150-g8ddc187 (2016-10-25, branch "next") Previously, config.h would end up with: #define I3_VERSION "4.12-150-g8ddc187 (2016-10-25, branch "next")" Note the unquoted double quotes around “next”, which are invalid in C string literals. Hence, this commit uses sed to escape double quotes, question marks and backslashes (see also http://stackoverflow.com/a/12208808/712014). The @<:@ and @:>@ quadrigraphs that m4 expands to [ and ], respectively, see also http://stackoverflow.com/a/2309394/712014
2016-10-25 22:35:30 +02:00
I3_VERSION="$(sed -e 's/@<:@\"?\\@:>@/\\&/g' ${srcdir}/I3_VERSION)"
Switch to autotools (GNU build system) This commit probably comes as a surprise to some, given that one of i3’s explicitly stated goals used to be “Do not use programs such as autoconf/automake for configuration and creating unreadable/broken makefiles”. I phrased this goal over 7 years ago, based largely on a grudge that I inherited, which — as I’ve realized in the meantime — was largely held against FOSS in general, and not actually nuanced criticism of autotools. In the meantime, I have come to realize that the knee-jerk reaction of “I could do this better!” (i.e. writing our own build system in this particular case) is usually misguided, and nowadays I strongly suggest trying hard to fix the existing system for the benefit of all existing and future users. Further, I recently got to experience the other side of the coin, as I packaged a new version of FreeRADIUS for Debian, which at the time of writing used autoconf in combination with boilermake, a custom make-based build system that only FreeRADIUS uses. Understanding the build system enough to fix issues and enable parallel compilation took me an entire day. That time is time which potentially every downstream maintainer needs to invest, and the resulting knowledge cannot be applied to any other project. Hence, I believe it’s a good idea switch i3 to autotools. Yes, it might be that particular features were easier to implement/understand in our custom Makefiles, and there might be individuals who have an easier time reading through our custom Makefiles than learning autotools. All of these considerations are outweighed by the benefits we get from using the same build system as literally thousands of other FOSS software packages. Aside from these somewhat philosophical considerations, there’s also practical improvements which this change brings us. See the “changes” section below. ┌──────────────────────────────────────────────────────────────────────────────┐ │ new workflow │ └──────────────────────────────────────────────────────────────────────────────┘ You can now build i3 like you build any other software package which uses autotools. Here’s a memory refresher: autoreconf -fi mkdir -p build && cd build ../configure make -j8 (The autoreconf -fi step is unnecessary if you are building from a release tarball, but shouldn’t hurt either.) ┌──────────────────────────────────────────────────────────────────────────────┐ │ recommended reading │ └──────────────────────────────────────────────────────────────────────────────┘ I very much recommend reading “A Practitioner's Guide to GNU Autoconf, Automake, and Libtool” by John Calcote (https://www.nostarch.com/autotools.htm). That book is from 2010 and, AFAICT, is the most up to date comprehensive description of autotools. Do not read older documentation. In particular, if a document you’re reading mentions configure.in (deprecated filename) or recursive make (now considered harmful), it’s likely outdated. ┌──────────────────────────────────────────────────────────────────────────────┐ │ changes │ └──────────────────────────────────────────────────────────────────────────────┘ This commit implements the following new functionality/changes in behavior: • We use the AX_ENABLE_BUILDDIR macro to enforce builds happening in a separate directory. This is a prerequisite for the AX_EXTEND_SRCDIR macro and building in a separate directory is common practice anyway. In case this causes any trouble when packaging i3 for your distribution, please let me know. • “make check” runs the i3 testsuite. You can still use ./testcases/complete-run.pl to get the interactive progress output. • “make distcheck” (runs testsuite on “make dist” result, tiny bit quicker feedback cycle than waiting for the travis build to catch the issue). • “make uninstall” (occasionally requested by users who compile from source) • “make” will build manpages/docs by default if the tools are installed. Conversely, manpages/docs are not tried to be built for users who don’t want to install all these dependencies to get started hacking on i3. • non-release builds will enable address sanitizer by default. Use the --disable-sanitizers configure option to turn off all sanitizers, and see --help for available sanitizers. • Support for pre-compiled headers (PCH) has been dropped for now in the interest of simplicitly. Maybe we can re-add it later. • coverage reports are now generated using “make check-code-coverage”, which requires specifying --enable-code-coverage when calling configure. ┌──────────────────────────────────────────────────────────────────────────────┐ │ build system feature parity/testing │ └──────────────────────────────────────────────────────────────────────────────┘ In addition to what’s described above, I tested the following features: • “make install” installs the same files (plus documentation and manpages) cd i3-old && make install PREFIX=/tmp/inst/old cd i3-new && ./configure --prefix=/tmp/inst/new cd /tmp/inst (cd old && for f in $(find); do [ -e "../new/$f" ] || echo "$f missing"; done) • make dist generates a tarball which includes the same files cd i3-old && make dist cd i3-new/x86_64-pc-linux-gnu && make dist colordiff -u <(tar tf i3-old/i3-4.12.tar.bz2 | sort) \ <(tar tf i3-new/x86_64-pc-linux-gnu/i3-4.12.tar.gz | sort) There are some expected differences: • Some files have been renamed (e.g. the new etc/ and share/ subdirectories) • Some files will now be generated at build-time, so only their corresponding .in file is shipped (e.g. testcases/complete-run.pl) • The generated parser files are shipped in the dist tarball (they only depend on the parser-specs/* files, not on the target system) • autotools infrastructure is shipped (e.g. “configure”, “missing”, etc.) • DLOG and ELOG statements still produce the same file name in logfiles • Listing source code in gdb still works. • gdb backtraces contain the i3-<version> path component • release.sh still works • version embedding 1. git checkout shows “4.12-136-gf720023 (2016-10-10, branch "autotools")” 2. tarball of a git version shows “4.12-non-git” 3. release tarball shows 4.13 • debug mode is enabled by default for non-release builds • enabling verbose builds via V=1 ┌──────────────────────────────────────────────────────────────────────────────┐ │ speed │ └──────────────────────────────────────────────────────────────────────────────┘ There is no noticeable difference in compilation speed itself (of binaries, documentation and manpages): i3-old $ time make all docs mans -j8 make all docs mans -j8 28.92s user 2.15s system 640% cpu 4.852 total i3-new $ time make -j8 make -j8 27.08s user 1.92s system 620% cpu 4.669 total In terms of one-time costs: configuring the build system (../configure) takes about 2.7s on my machine, generating the build system (autoreconf -fi) takes about 3.1s on my machine. ┌──────────────────────────────────────────────────────────────────────────────┐ │ m4 macros │ └──────────────────────────────────────────────────────────────────────────────┘ All files in m4/ have been copied from the autoconf-archive package in version b6aeb1988f4b6c78bf39d97b6c4f6e1d594d59b9 and should be updated whenever they change. This commit has been tested with autoconf 2.69 and automake 1.15.
2016-10-07 13:48:26 +02:00
is_release="$(grep -q non-git ${srcdir}/I3_VERSION && echo no || echo yes)"
])
Update travis for autotools
2016-10-16 18:03:09 +02:00
AC_SUBST([I3_VERSION], [$I3_VERSION])
Switch to autotools (GNU build system) This commit probably comes as a surprise to some, given that one of i3’s explicitly stated goals used to be “Do not use programs such as autoconf/automake for configuration and creating unreadable/broken makefiles”. I phrased this goal over 7 years ago, based largely on a grudge that I inherited, which — as I’ve realized in the meantime — was largely held against FOSS in general, and not actually nuanced criticism of autotools. In the meantime, I have come to realize that the knee-jerk reaction of “I could do this better!” (i.e. writing our own build system in this particular case) is usually misguided, and nowadays I strongly suggest trying hard to fix the existing system for the benefit of all existing and future users. Further, I recently got to experience the other side of the coin, as I packaged a new version of FreeRADIUS for Debian, which at the time of writing used autoconf in combination with boilermake, a custom make-based build system that only FreeRADIUS uses. Understanding the build system enough to fix issues and enable parallel compilation took me an entire day. That time is time which potentially every downstream maintainer needs to invest, and the resulting knowledge cannot be applied to any other project. Hence, I believe it’s a good idea switch i3 to autotools. Yes, it might be that particular features were easier to implement/understand in our custom Makefiles, and there might be individuals who have an easier time reading through our custom Makefiles than learning autotools. All of these considerations are outweighed by the benefits we get from using the same build system as literally thousands of other FOSS software packages. Aside from these somewhat philosophical considerations, there’s also practical improvements which this change brings us. See the “changes” section below. ┌──────────────────────────────────────────────────────────────────────────────┐ │ new workflow │ └──────────────────────────────────────────────────────────────────────────────┘ You can now build i3 like you build any other software package which uses autotools. Here’s a memory refresher: autoreconf -fi mkdir -p build && cd build ../configure make -j8 (The autoreconf -fi step is unnecessary if you are building from a release tarball, but shouldn’t hurt either.) ┌──────────────────────────────────────────────────────────────────────────────┐ │ recommended reading │ └──────────────────────────────────────────────────────────────────────────────┘ I very much recommend reading “A Practitioner's Guide to GNU Autoconf, Automake, and Libtool” by John Calcote (https://www.nostarch.com/autotools.htm). That book is from 2010 and, AFAICT, is the most up to date comprehensive description of autotools. Do not read older documentation. In particular, if a document you’re reading mentions configure.in (deprecated filename) or recursive make (now considered harmful), it’s likely outdated. ┌──────────────────────────────────────────────────────────────────────────────┐ │ changes │ └──────────────────────────────────────────────────────────────────────────────┘ This commit implements the following new functionality/changes in behavior: • We use the AX_ENABLE_BUILDDIR macro to enforce builds happening in a separate directory. This is a prerequisite for the AX_EXTEND_SRCDIR macro and building in a separate directory is common practice anyway. In case this causes any trouble when packaging i3 for your distribution, please let me know. • “make check” runs the i3 testsuite. You can still use ./testcases/complete-run.pl to get the interactive progress output. • “make distcheck” (runs testsuite on “make dist” result, tiny bit quicker feedback cycle than waiting for the travis build to catch the issue). • “make uninstall” (occasionally requested by users who compile from source) • “make” will build manpages/docs by default if the tools are installed. Conversely, manpages/docs are not tried to be built for users who don’t want to install all these dependencies to get started hacking on i3. • non-release builds will enable address sanitizer by default. Use the --disable-sanitizers configure option to turn off all sanitizers, and see --help for available sanitizers. • Support for pre-compiled headers (PCH) has been dropped for now in the interest of simplicitly. Maybe we can re-add it later. • coverage reports are now generated using “make check-code-coverage”, which requires specifying --enable-code-coverage when calling configure. ┌──────────────────────────────────────────────────────────────────────────────┐ │ build system feature parity/testing │ └──────────────────────────────────────────────────────────────────────────────┘ In addition to what’s described above, I tested the following features: • “make install” installs the same files (plus documentation and manpages) cd i3-old && make install PREFIX=/tmp/inst/old cd i3-new && ./configure --prefix=/tmp/inst/new cd /tmp/inst (cd old && for f in $(find); do [ -e "../new/$f" ] || echo "$f missing"; done) • make dist generates a tarball which includes the same files cd i3-old && make dist cd i3-new/x86_64-pc-linux-gnu && make dist colordiff -u <(tar tf i3-old/i3-4.12.tar.bz2 | sort) \ <(tar tf i3-new/x86_64-pc-linux-gnu/i3-4.12.tar.gz | sort) There are some expected differences: • Some files have been renamed (e.g. the new etc/ and share/ subdirectories) • Some files will now be generated at build-time, so only their corresponding .in file is shipped (e.g. testcases/complete-run.pl) • The generated parser files are shipped in the dist tarball (they only depend on the parser-specs/* files, not on the target system) • autotools infrastructure is shipped (e.g. “configure”, “missing”, etc.) • DLOG and ELOG statements still produce the same file name in logfiles • Listing source code in gdb still works. • gdb backtraces contain the i3-<version> path component • release.sh still works • version embedding 1. git checkout shows “4.12-136-gf720023 (2016-10-10, branch "autotools")” 2. tarball of a git version shows “4.12-non-git” 3. release tarball shows 4.13 • debug mode is enabled by default for non-release builds • enabling verbose builds via V=1 ┌──────────────────────────────────────────────────────────────────────────────┐ │ speed │ └──────────────────────────────────────────────────────────────────────────────┘ There is no noticeable difference in compilation speed itself (of binaries, documentation and manpages): i3-old $ time make all docs mans -j8 make all docs mans -j8 28.92s user 2.15s system 640% cpu 4.852 total i3-new $ time make -j8 make -j8 27.08s user 1.92s system 620% cpu 4.669 total In terms of one-time costs: configuring the build system (../configure) takes about 2.7s on my machine, generating the build system (autoreconf -fi) takes about 3.1s on my machine. ┌──────────────────────────────────────────────────────────────────────────────┐ │ m4 macros │ └──────────────────────────────────────────────────────────────────────────────┘ All files in m4/ have been copied from the autoconf-archive package in version b6aeb1988f4b6c78bf39d97b6c4f6e1d594d59b9 and should be updated whenever they change. This commit has been tested with autoconf 2.69 and automake 1.15.
2016-10-07 13:48:26 +02:00
MAJOR_VERSION="$(echo ${VERSION} | cut -d '.' -f 1)"
MINOR_VERSION="$(echo ${VERSION} | cut -d '.' -f 2)"
PATCH_VERSION="$(echo ${VERSION} | cut -d '.' -f 3)"
AS_IF([test "x${PATCH_VERSION}" = x], [PATCH_VERSION=0])
AC_DEFINE_UNQUOTED([I3_VERSION], ["${I3_VERSION}"], [i3 version])
AC_DEFINE_UNQUOTED([MAJOR_VERSION], [${MAJOR_VERSION}], [i3 major version])
AC_DEFINE_UNQUOTED([MINOR_VERSION], [${MINOR_VERSION}], [i3 minor version])
AC_DEFINE_UNQUOTED([PATCH_VERSION], [${PATCH_VERSION}], [i3 patch version])
AX_CODE_COVERAGE
dnl is_release must be lowercase because AX_CHECK_ENABLE_DEBUG calls m4_tolower
dnl on its fourth argument.
AX_CHECK_ENABLE_DEBUG([yes], , [UNUSED_NDEBUG], [$is_release])
AC_PROG_CC_C99
# For strnlen() and vasprintf().
AC_USE_SYSTEM_EXTENSIONS
# Checks for typedefs, structures, and compiler characteristics.
AC_CHECK_HEADER_STDBOOL
dnl The error message should include the specific type which could not be
dnl found, but I do not see a way to achieve that.
AC_CHECK_TYPES([mode_t, off_t, pid_t, size_t, ssize_t], , [AC_MSG_FAILURE([cannot find required type])])
# Checks for library functions.
AC_FUNC_FORK
AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK
AC_FUNC_STRNLEN
Use AC_REPLACE_FUNCS strndup is removed from AC_CHECK_FUNCS since it will be provided if not found. Fixes #2610
2019-10-13 12:12:14 +02:00
AC_CHECK_FUNCS([atexit dup2 ftruncate getcwd gettimeofday localtime_r memchr memset mkdir rmdir setlocale socket strcasecmp strchr strdup strerror strncasecmp strrchr strspn strstr strtol strtoul], , [AC_MSG_FAILURE([cannot find the $ac_func function, which i3 requires])])
AC_REPLACE_FUNCS([mkdirp strndup])
Switch to autotools (GNU build system) This commit probably comes as a surprise to some, given that one of i3’s explicitly stated goals used to be “Do not use programs such as autoconf/automake for configuration and creating unreadable/broken makefiles”. I phrased this goal over 7 years ago, based largely on a grudge that I inherited, which — as I’ve realized in the meantime — was largely held against FOSS in general, and not actually nuanced criticism of autotools. In the meantime, I have come to realize that the knee-jerk reaction of “I could do this better!” (i.e. writing our own build system in this particular case) is usually misguided, and nowadays I strongly suggest trying hard to fix the existing system for the benefit of all existing and future users. Further, I recently got to experience the other side of the coin, as I packaged a new version of FreeRADIUS for Debian, which at the time of writing used autoconf in combination with boilermake, a custom make-based build system that only FreeRADIUS uses. Understanding the build system enough to fix issues and enable parallel compilation took me an entire day. That time is time which potentially every downstream maintainer needs to invest, and the resulting knowledge cannot be applied to any other project. Hence, I believe it’s a good idea switch i3 to autotools. Yes, it might be that particular features were easier to implement/understand in our custom Makefiles, and there might be individuals who have an easier time reading through our custom Makefiles than learning autotools. All of these considerations are outweighed by the benefits we get from using the same build system as literally thousands of other FOSS software packages. Aside from these somewhat philosophical considerations, there’s also practical improvements which this change brings us. See the “changes” section below. ┌──────────────────────────────────────────────────────────────────────────────┐ │ new workflow │ └──────────────────────────────────────────────────────────────────────────────┘ You can now build i3 like you build any other software package which uses autotools. Here’s a memory refresher: autoreconf -fi mkdir -p build && cd build ../configure make -j8 (The autoreconf -fi step is unnecessary if you are building from a release tarball, but shouldn’t hurt either.) ┌──────────────────────────────────────────────────────────────────────────────┐ │ recommended reading │ └──────────────────────────────────────────────────────────────────────────────┘ I very much recommend reading “A Practitioner's Guide to GNU Autoconf, Automake, and Libtool” by John Calcote (https://www.nostarch.com/autotools.htm). That book is from 2010 and, AFAICT, is the most up to date comprehensive description of autotools. Do not read older documentation. In particular, if a document you’re reading mentions configure.in (deprecated filename) or recursive make (now considered harmful), it’s likely outdated. ┌──────────────────────────────────────────────────────────────────────────────┐ │ changes │ └──────────────────────────────────────────────────────────────────────────────┘ This commit implements the following new functionality/changes in behavior: • We use the AX_ENABLE_BUILDDIR macro to enforce builds happening in a separate directory. This is a prerequisite for the AX_EXTEND_SRCDIR macro and building in a separate directory is common practice anyway. In case this causes any trouble when packaging i3 for your distribution, please let me know. • “make check” runs the i3 testsuite. You can still use ./testcases/complete-run.pl to get the interactive progress output. • “make distcheck” (runs testsuite on “make dist” result, tiny bit quicker feedback cycle than waiting for the travis build to catch the issue). • “make uninstall” (occasionally requested by users who compile from source) • “make” will build manpages/docs by default if the tools are installed. Conversely, manpages/docs are not tried to be built for users who don’t want to install all these dependencies to get started hacking on i3. • non-release builds will enable address sanitizer by default. Use the --disable-sanitizers configure option to turn off all sanitizers, and see --help for available sanitizers. • Support for pre-compiled headers (PCH) has been dropped for now in the interest of simplicitly. Maybe we can re-add it later. • coverage reports are now generated using “make check-code-coverage”, which requires specifying --enable-code-coverage when calling configure. ┌──────────────────────────────────────────────────────────────────────────────┐ │ build system feature parity/testing │ └──────────────────────────────────────────────────────────────────────────────┘ In addition to what’s described above, I tested the following features: • “make install” installs the same files (plus documentation and manpages) cd i3-old && make install PREFIX=/tmp/inst/old cd i3-new && ./configure --prefix=/tmp/inst/new cd /tmp/inst (cd old && for f in $(find); do [ -e "../new/$f" ] || echo "$f missing"; done) • make dist generates a tarball which includes the same files cd i3-old && make dist cd i3-new/x86_64-pc-linux-gnu && make dist colordiff -u <(tar tf i3-old/i3-4.12.tar.bz2 | sort) \ <(tar tf i3-new/x86_64-pc-linux-gnu/i3-4.12.tar.gz | sort) There are some expected differences: • Some files have been renamed (e.g. the new etc/ and share/ subdirectories) • Some files will now be generated at build-time, so only their corresponding .in file is shipped (e.g. testcases/complete-run.pl) • The generated parser files are shipped in the dist tarball (they only depend on the parser-specs/* files, not on the target system) • autotools infrastructure is shipped (e.g. “configure”, “missing”, etc.) • DLOG and ELOG statements still produce the same file name in logfiles • Listing source code in gdb still works. • gdb backtraces contain the i3-<version> path component • release.sh still works • version embedding 1. git checkout shows “4.12-136-gf720023 (2016-10-10, branch "autotools")” 2. tarball of a git version shows “4.12-non-git” 3. release tarball shows 4.13 • debug mode is enabled by default for non-release builds • enabling verbose builds via V=1 ┌──────────────────────────────────────────────────────────────────────────────┐ │ speed │ └──────────────────────────────────────────────────────────────────────────────┘ There is no noticeable difference in compilation speed itself (of binaries, documentation and manpages): i3-old $ time make all docs mans -j8 make all docs mans -j8 28.92s user 2.15s system 640% cpu 4.852 total i3-new $ time make -j8 make -j8 27.08s user 1.92s system 620% cpu 4.669 total In terms of one-time costs: configuring the build system (../configure) takes about 2.7s on my machine, generating the build system (autoreconf -fi) takes about 3.1s on my machine. ┌──────────────────────────────────────────────────────────────────────────────┐ │ m4 macros │ └──────────────────────────────────────────────────────────────────────────────┘ All files in m4/ have been copied from the autoconf-archive package in version b6aeb1988f4b6c78bf39d97b6c4f6e1d594d59b9 and should be updated whenever they change. This commit has been tested with autoconf 2.69 and automake 1.15.
2016-10-07 13:48:26 +02:00
# Checks for libraries.
AC_SEARCH_LIBS([floor], [m], , [AC_MSG_FAILURE([cannot find the required floor() function despite trying to link with -lm])])
# libev does not ship with a pkg-config file :(.
AC_SEARCH_LIBS([ev_run], [ev], , [AC_MSG_FAILURE([cannot find the required ev_run() function despite trying to link with -lev])])
configure.ac: fix AC_SEARCH_LIBS([shm_open]) for static linking (#3379) Without specifying -pthread, the conftest fails and -lrt is missing during compilation of i3, resulting in a failing build.
2018-08-31 16:59:08 +02:00
AC_SEARCH_LIBS([shm_open], [rt], [], [], [-pthread])
Switch to autotools (GNU build system) This commit probably comes as a surprise to some, given that one of i3’s explicitly stated goals used to be “Do not use programs such as autoconf/automake for configuration and creating unreadable/broken makefiles”. I phrased this goal over 7 years ago, based largely on a grudge that I inherited, which — as I’ve realized in the meantime — was largely held against FOSS in general, and not actually nuanced criticism of autotools. In the meantime, I have come to realize that the knee-jerk reaction of “I could do this better!” (i.e. writing our own build system in this particular case) is usually misguided, and nowadays I strongly suggest trying hard to fix the existing system for the benefit of all existing and future users. Further, I recently got to experience the other side of the coin, as I packaged a new version of FreeRADIUS for Debian, which at the time of writing used autoconf in combination with boilermake, a custom make-based build system that only FreeRADIUS uses. Understanding the build system enough to fix issues and enable parallel compilation took me an entire day. That time is time which potentially every downstream maintainer needs to invest, and the resulting knowledge cannot be applied to any other project. Hence, I believe it’s a good idea switch i3 to autotools. Yes, it might be that particular features were easier to implement/understand in our custom Makefiles, and there might be individuals who have an easier time reading through our custom Makefiles than learning autotools. All of these considerations are outweighed by the benefits we get from using the same build system as literally thousands of other FOSS software packages. Aside from these somewhat philosophical considerations, there’s also practical improvements which this change brings us. See the “changes” section below. ┌──────────────────────────────────────────────────────────────────────────────┐ │ new workflow │ └──────────────────────────────────────────────────────────────────────────────┘ You can now build i3 like you build any other software package which uses autotools. Here’s a memory refresher: autoreconf -fi mkdir -p build && cd build ../configure make -j8 (The autoreconf -fi step is unnecessary if you are building from a release tarball, but shouldn’t hurt either.) ┌──────────────────────────────────────────────────────────────────────────────┐ │ recommended reading │ └──────────────────────────────────────────────────────────────────────────────┘ I very much recommend reading “A Practitioner's Guide to GNU Autoconf, Automake, and Libtool” by John Calcote (https://www.nostarch.com/autotools.htm). That book is from 2010 and, AFAICT, is the most up to date comprehensive description of autotools. Do not read older documentation. In particular, if a document you’re reading mentions configure.in (deprecated filename) or recursive make (now considered harmful), it’s likely outdated. ┌──────────────────────────────────────────────────────────────────────────────┐ │ changes │ └──────────────────────────────────────────────────────────────────────────────┘ This commit implements the following new functionality/changes in behavior: • We use the AX_ENABLE_BUILDDIR macro to enforce builds happening in a separate directory. This is a prerequisite for the AX_EXTEND_SRCDIR macro and building in a separate directory is common practice anyway. In case this causes any trouble when packaging i3 for your distribution, please let me know. • “make check” runs the i3 testsuite. You can still use ./testcases/complete-run.pl to get the interactive progress output. • “make distcheck” (runs testsuite on “make dist” result, tiny bit quicker feedback cycle than waiting for the travis build to catch the issue). • “make uninstall” (occasionally requested by users who compile from source) • “make” will build manpages/docs by default if the tools are installed. Conversely, manpages/docs are not tried to be built for users who don’t want to install all these dependencies to get started hacking on i3. • non-release builds will enable address sanitizer by default. Use the --disable-sanitizers configure option to turn off all sanitizers, and see --help for available sanitizers. • Support for pre-compiled headers (PCH) has been dropped for now in the interest of simplicitly. Maybe we can re-add it later. • coverage reports are now generated using “make check-code-coverage”, which requires specifying --enable-code-coverage when calling configure. ┌──────────────────────────────────────────────────────────────────────────────┐ │ build system feature parity/testing │ └──────────────────────────────────────────────────────────────────────────────┘ In addition to what’s described above, I tested the following features: • “make install” installs the same files (plus documentation and manpages) cd i3-old && make install PREFIX=/tmp/inst/old cd i3-new && ./configure --prefix=/tmp/inst/new cd /tmp/inst (cd old && for f in $(find); do [ -e "../new/$f" ] || echo "$f missing"; done) • make dist generates a tarball which includes the same files cd i3-old && make dist cd i3-new/x86_64-pc-linux-gnu && make dist colordiff -u <(tar tf i3-old/i3-4.12.tar.bz2 | sort) \ <(tar tf i3-new/x86_64-pc-linux-gnu/i3-4.12.tar.gz | sort) There are some expected differences: • Some files have been renamed (e.g. the new etc/ and share/ subdirectories) • Some files will now be generated at build-time, so only their corresponding .in file is shipped (e.g. testcases/complete-run.pl) • The generated parser files are shipped in the dist tarball (they only depend on the parser-specs/* files, not on the target system) • autotools infrastructure is shipped (e.g. “configure”, “missing”, etc.) • DLOG and ELOG statements still produce the same file name in logfiles • Listing source code in gdb still works. • gdb backtraces contain the i3-<version> path component • release.sh still works • version embedding 1. git checkout shows “4.12-136-gf720023 (2016-10-10, branch "autotools")” 2. tarball of a git version shows “4.12-non-git” 3. release tarball shows 4.13 • debug mode is enabled by default for non-release builds • enabling verbose builds via V=1 ┌──────────────────────────────────────────────────────────────────────────────┐ │ speed │ └──────────────────────────────────────────────────────────────────────────────┘ There is no noticeable difference in compilation speed itself (of binaries, documentation and manpages): i3-old $ time make all docs mans -j8 make all docs mans -j8 28.92s user 2.15s system 640% cpu 4.852 total i3-new $ time make -j8 make -j8 27.08s user 1.92s system 620% cpu 4.669 total In terms of one-time costs: configuring the build system (../configure) takes about 2.7s on my machine, generating the build system (autoreconf -fi) takes about 3.1s on my machine. ┌──────────────────────────────────────────────────────────────────────────────┐ │ m4 macros │ └──────────────────────────────────────────────────────────────────────────────┘ All files in m4/ have been copied from the autoconf-archive package in version b6aeb1988f4b6c78bf39d97b6c4f6e1d594d59b9 and should be updated whenever they change. This commit has been tested with autoconf 2.69 and automake 1.15.
2016-10-07 13:48:26 +02:00
Added libiconv to search libs for OpenBSD patch (#3336)
2018-08-04 19:27:25 +02:00
AC_SEARCH_LIBS([iconv_open], [iconv], ,
AC_SEARCH_LIBS([libiconv_open], [iconv], , [AC_MSG_FAILURE([cannot find the required iconv_open() function despite trying to link with -liconv])]))
Some systems need to link to libiconv explicitly, thus add a check for it. (#2586)
2016-12-02 19:06:39 +01:00
Switch to autotools (GNU build system) This commit probably comes as a surprise to some, given that one of i3’s explicitly stated goals used to be “Do not use programs such as autoconf/automake for configuration and creating unreadable/broken makefiles”. I phrased this goal over 7 years ago, based largely on a grudge that I inherited, which — as I’ve realized in the meantime — was largely held against FOSS in general, and not actually nuanced criticism of autotools. In the meantime, I have come to realize that the knee-jerk reaction of “I could do this better!” (i.e. writing our own build system in this particular case) is usually misguided, and nowadays I strongly suggest trying hard to fix the existing system for the benefit of all existing and future users. Further, I recently got to experience the other side of the coin, as I packaged a new version of FreeRADIUS for Debian, which at the time of writing used autoconf in combination with boilermake, a custom make-based build system that only FreeRADIUS uses. Understanding the build system enough to fix issues and enable parallel compilation took me an entire day. That time is time which potentially every downstream maintainer needs to invest, and the resulting knowledge cannot be applied to any other project. Hence, I believe it’s a good idea switch i3 to autotools. Yes, it might be that particular features were easier to implement/understand in our custom Makefiles, and there might be individuals who have an easier time reading through our custom Makefiles than learning autotools. All of these considerations are outweighed by the benefits we get from using the same build system as literally thousands of other FOSS software packages. Aside from these somewhat philosophical considerations, there’s also practical improvements which this change brings us. See the “changes” section below. ┌──────────────────────────────────────────────────────────────────────────────┐ │ new workflow │ └──────────────────────────────────────────────────────────────────────────────┘ You can now build i3 like you build any other software package which uses autotools. Here’s a memory refresher: autoreconf -fi mkdir -p build && cd build ../configure make -j8 (The autoreconf -fi step is unnecessary if you are building from a release tarball, but shouldn’t hurt either.) ┌──────────────────────────────────────────────────────────────────────────────┐ │ recommended reading │ └──────────────────────────────────────────────────────────────────────────────┘ I very much recommend reading “A Practitioner's Guide to GNU Autoconf, Automake, and Libtool” by John Calcote (https://www.nostarch.com/autotools.htm). That book is from 2010 and, AFAICT, is the most up to date comprehensive description of autotools. Do not read older documentation. In particular, if a document you’re reading mentions configure.in (deprecated filename) or recursive make (now considered harmful), it’s likely outdated. ┌──────────────────────────────────────────────────────────────────────────────┐ │ changes │ └──────────────────────────────────────────────────────────────────────────────┘ This commit implements the following new functionality/changes in behavior: • We use the AX_ENABLE_BUILDDIR macro to enforce builds happening in a separate directory. This is a prerequisite for the AX_EXTEND_SRCDIR macro and building in a separate directory is common practice anyway. In case this causes any trouble when packaging i3 for your distribution, please let me know. • “make check” runs the i3 testsuite. You can still use ./testcases/complete-run.pl to get the interactive progress output. • “make distcheck” (runs testsuite on “make dist” result, tiny bit quicker feedback cycle than waiting for the travis build to catch the issue). • “make uninstall” (occasionally requested by users who compile from source) • “make” will build manpages/docs by default if the tools are installed. Conversely, manpages/docs are not tried to be built for users who don’t want to install all these dependencies to get started hacking on i3. • non-release builds will enable address sanitizer by default. Use the --disable-sanitizers configure option to turn off all sanitizers, and see --help for available sanitizers. • Support for pre-compiled headers (PCH) has been dropped for now in the interest of simplicitly. Maybe we can re-add it later. • coverage reports are now generated using “make check-code-coverage”, which requires specifying --enable-code-coverage when calling configure. ┌──────────────────────────────────────────────────────────────────────────────┐ │ build system feature parity/testing │ └──────────────────────────────────────────────────────────────────────────────┘ In addition to what’s described above, I tested the following features: • “make install” installs the same files (plus documentation and manpages) cd i3-old && make install PREFIX=/tmp/inst/old cd i3-new && ./configure --prefix=/tmp/inst/new cd /tmp/inst (cd old && for f in $(find); do [ -e "../new/$f" ] || echo "$f missing"; done) • make dist generates a tarball which includes the same files cd i3-old && make dist cd i3-new/x86_64-pc-linux-gnu && make dist colordiff -u <(tar tf i3-old/i3-4.12.tar.bz2 | sort) \ <(tar tf i3-new/x86_64-pc-linux-gnu/i3-4.12.tar.gz | sort) There are some expected differences: • Some files have been renamed (e.g. the new etc/ and share/ subdirectories) • Some files will now be generated at build-time, so only their corresponding .in file is shipped (e.g. testcases/complete-run.pl) • The generated parser files are shipped in the dist tarball (they only depend on the parser-specs/* files, not on the target system) • autotools infrastructure is shipped (e.g. “configure”, “missing”, etc.) • DLOG and ELOG statements still produce the same file name in logfiles • Listing source code in gdb still works. • gdb backtraces contain the i3-<version> path component • release.sh still works • version embedding 1. git checkout shows “4.12-136-gf720023 (2016-10-10, branch "autotools")” 2. tarball of a git version shows “4.12-non-git” 3. release tarball shows 4.13 • debug mode is enabled by default for non-release builds • enabling verbose builds via V=1 ┌──────────────────────────────────────────────────────────────────────────────┐ │ speed │ └──────────────────────────────────────────────────────────────────────────────┘ There is no noticeable difference in compilation speed itself (of binaries, documentation and manpages): i3-old $ time make all docs mans -j8 make all docs mans -j8 28.92s user 2.15s system 640% cpu 4.852 total i3-new $ time make -j8 make -j8 27.08s user 1.92s system 620% cpu 4.669 total In terms of one-time costs: configuring the build system (../configure) takes about 2.7s on my machine, generating the build system (autoreconf -fi) takes about 3.1s on my machine. ┌──────────────────────────────────────────────────────────────────────────────┐ │ m4 macros │ └──────────────────────────────────────────────────────────────────────────────┘ All files in m4/ have been copied from the autoconf-archive package in version b6aeb1988f4b6c78bf39d97b6c4f6e1d594d59b9 and should be updated whenever they change. This commit has been tested with autoconf 2.69 and automake 1.15.
2016-10-07 13:48:26 +02:00
AX_PTHREAD
dnl Each prefix corresponds to a source tarball which users might have
dnl downloaded in a newer version and would like to overwrite.
PKG_CHECK_MODULES([LIBSN], [libstartup-notification-1.0])
Add input and bounding shapes support (#2742) Basic idea: if the window has a shape, set the parent container shape as the union of the window shape and the shape of the frame borders. Co-authored-by: Uli Schlachter <psychon@znc.in>
2018-11-09 00:19:08 +01:00
PKG_CHECK_MODULES([XCB], [xcb xcb-xkb xcb-xinerama xcb-randr xcb-shape])
Switch to autotools (GNU build system) This commit probably comes as a surprise to some, given that one of i3’s explicitly stated goals used to be “Do not use programs such as autoconf/automake for configuration and creating unreadable/broken makefiles”. I phrased this goal over 7 years ago, based largely on a grudge that I inherited, which — as I’ve realized in the meantime — was largely held against FOSS in general, and not actually nuanced criticism of autotools. In the meantime, I have come to realize that the knee-jerk reaction of “I could do this better!” (i.e. writing our own build system in this particular case) is usually misguided, and nowadays I strongly suggest trying hard to fix the existing system for the benefit of all existing and future users. Further, I recently got to experience the other side of the coin, as I packaged a new version of FreeRADIUS for Debian, which at the time of writing used autoconf in combination with boilermake, a custom make-based build system that only FreeRADIUS uses. Understanding the build system enough to fix issues and enable parallel compilation took me an entire day. That time is time which potentially every downstream maintainer needs to invest, and the resulting knowledge cannot be applied to any other project. Hence, I believe it’s a good idea switch i3 to autotools. Yes, it might be that particular features were easier to implement/understand in our custom Makefiles, and there might be individuals who have an easier time reading through our custom Makefiles than learning autotools. All of these considerations are outweighed by the benefits we get from using the same build system as literally thousands of other FOSS software packages. Aside from these somewhat philosophical considerations, there’s also practical improvements which this change brings us. See the “changes” section below. ┌──────────────────────────────────────────────────────────────────────────────┐ │ new workflow │ └──────────────────────────────────────────────────────────────────────────────┘ You can now build i3 like you build any other software package which uses autotools. Here’s a memory refresher: autoreconf -fi mkdir -p build && cd build ../configure make -j8 (The autoreconf -fi step is unnecessary if you are building from a release tarball, but shouldn’t hurt either.) ┌──────────────────────────────────────────────────────────────────────────────┐ │ recommended reading │ └──────────────────────────────────────────────────────────────────────────────┘ I very much recommend reading “A Practitioner's Guide to GNU Autoconf, Automake, and Libtool” by John Calcote (https://www.nostarch.com/autotools.htm). That book is from 2010 and, AFAICT, is the most up to date comprehensive description of autotools. Do not read older documentation. In particular, if a document you’re reading mentions configure.in (deprecated filename) or recursive make (now considered harmful), it’s likely outdated. ┌──────────────────────────────────────────────────────────────────────────────┐ │ changes │ └──────────────────────────────────────────────────────────────────────────────┘ This commit implements the following new functionality/changes in behavior: • We use the AX_ENABLE_BUILDDIR macro to enforce builds happening in a separate directory. This is a prerequisite for the AX_EXTEND_SRCDIR macro and building in a separate directory is common practice anyway. In case this causes any trouble when packaging i3 for your distribution, please let me know. • “make check” runs the i3 testsuite. You can still use ./testcases/complete-run.pl to get the interactive progress output. • “make distcheck” (runs testsuite on “make dist” result, tiny bit quicker feedback cycle than waiting for the travis build to catch the issue). • “make uninstall” (occasionally requested by users who compile from source) • “make” will build manpages/docs by default if the tools are installed. Conversely, manpages/docs are not tried to be built for users who don’t want to install all these dependencies to get started hacking on i3. • non-release builds will enable address sanitizer by default. Use the --disable-sanitizers configure option to turn off all sanitizers, and see --help for available sanitizers. • Support for pre-compiled headers (PCH) has been dropped for now in the interest of simplicitly. Maybe we can re-add it later. • coverage reports are now generated using “make check-code-coverage”, which requires specifying --enable-code-coverage when calling configure. ┌──────────────────────────────────────────────────────────────────────────────┐ │ build system feature parity/testing │ └──────────────────────────────────────────────────────────────────────────────┘ In addition to what’s described above, I tested the following features: • “make install” installs the same files (plus documentation and manpages) cd i3-old && make install PREFIX=/tmp/inst/old cd i3-new && ./configure --prefix=/tmp/inst/new cd /tmp/inst (cd old && for f in $(find); do [ -e "../new/$f" ] || echo "$f missing"; done) • make dist generates a tarball which includes the same files cd i3-old && make dist cd i3-new/x86_64-pc-linux-gnu && make dist colordiff -u <(tar tf i3-old/i3-4.12.tar.bz2 | sort) \ <(tar tf i3-new/x86_64-pc-linux-gnu/i3-4.12.tar.gz | sort) There are some expected differences: • Some files have been renamed (e.g. the new etc/ and share/ subdirectories) • Some files will now be generated at build-time, so only their corresponding .in file is shipped (e.g. testcases/complete-run.pl) • The generated parser files are shipped in the dist tarball (they only depend on the parser-specs/* files, not on the target system) • autotools infrastructure is shipped (e.g. “configure”, “missing”, etc.) • DLOG and ELOG statements still produce the same file name in logfiles • Listing source code in gdb still works. • gdb backtraces contain the i3-<version> path component • release.sh still works • version embedding 1. git checkout shows “4.12-136-gf720023 (2016-10-10, branch "autotools")” 2. tarball of a git version shows “4.12-non-git” 3. release tarball shows 4.13 • debug mode is enabled by default for non-release builds • enabling verbose builds via V=1 ┌──────────────────────────────────────────────────────────────────────────────┐ │ speed │ └──────────────────────────────────────────────────────────────────────────────┘ There is no noticeable difference in compilation speed itself (of binaries, documentation and manpages): i3-old $ time make all docs mans -j8 make all docs mans -j8 28.92s user 2.15s system 640% cpu 4.852 total i3-new $ time make -j8 make -j8 27.08s user 1.92s system 620% cpu 4.669 total In terms of one-time costs: configuring the build system (../configure) takes about 2.7s on my machine, generating the build system (autoreconf -fi) takes about 3.1s on my machine. ┌──────────────────────────────────────────────────────────────────────────────┐ │ m4 macros │ └──────────────────────────────────────────────────────────────────────────────┘ All files in m4/ have been copied from the autoconf-archive package in version b6aeb1988f4b6c78bf39d97b6c4f6e1d594d59b9 and should be updated whenever they change. This commit has been tested with autoconf 2.69 and automake 1.15.
2016-10-07 13:48:26 +02:00
PKG_CHECK_MODULES([XCB_UTIL], [xcb-event xcb-util])
PKG_CHECK_MODULES([XCB_UTIL_CURSOR], [xcb-cursor])
PKG_CHECK_MODULES([XCB_UTIL_KEYSYMS], [xcb-keysyms])
PKG_CHECK_MODULES([XCB_UTIL_WM], [xcb-icccm])
PKG_CHECK_MODULES([XCB_UTIL_XRM], [xcb-xrm])
PKG_CHECK_MODULES([XKBCOMMON], [xkbcommon xkbcommon-x11])
PKG_CHECK_MODULES([YAJL], [yajl])
PKG_CHECK_MODULES([LIBPCRE], [libpcre >= 8.10])
PKG_CHECK_MODULES([PANGOCAIRO], [cairo >= 1.14.4 pangocairo])
Add explicit reference to glib2 to automake
2019-03-21 05:51:13 +01:00
PKG_CHECK_MODULES([GLIBGOBJECT], [glib-2.0 gobject-2.0])
Switch to autotools (GNU build system) This commit probably comes as a surprise to some, given that one of i3’s explicitly stated goals used to be “Do not use programs such as autoconf/automake for configuration and creating unreadable/broken makefiles”. I phrased this goal over 7 years ago, based largely on a grudge that I inherited, which — as I’ve realized in the meantime — was largely held against FOSS in general, and not actually nuanced criticism of autotools. In the meantime, I have come to realize that the knee-jerk reaction of “I could do this better!” (i.e. writing our own build system in this particular case) is usually misguided, and nowadays I strongly suggest trying hard to fix the existing system for the benefit of all existing and future users. Further, I recently got to experience the other side of the coin, as I packaged a new version of FreeRADIUS for Debian, which at the time of writing used autoconf in combination with boilermake, a custom make-based build system that only FreeRADIUS uses. Understanding the build system enough to fix issues and enable parallel compilation took me an entire day. That time is time which potentially every downstream maintainer needs to invest, and the resulting knowledge cannot be applied to any other project. Hence, I believe it’s a good idea switch i3 to autotools. Yes, it might be that particular features were easier to implement/understand in our custom Makefiles, and there might be individuals who have an easier time reading through our custom Makefiles than learning autotools. All of these considerations are outweighed by the benefits we get from using the same build system as literally thousands of other FOSS software packages. Aside from these somewhat philosophical considerations, there’s also practical improvements which this change brings us. See the “changes” section below. ┌──────────────────────────────────────────────────────────────────────────────┐ │ new workflow │ └──────────────────────────────────────────────────────────────────────────────┘ You can now build i3 like you build any other software package which uses autotools. Here’s a memory refresher: autoreconf -fi mkdir -p build && cd build ../configure make -j8 (The autoreconf -fi step is unnecessary if you are building from a release tarball, but shouldn’t hurt either.) ┌──────────────────────────────────────────────────────────────────────────────┐ │ recommended reading │ └──────────────────────────────────────────────────────────────────────────────┘ I very much recommend reading “A Practitioner's Guide to GNU Autoconf, Automake, and Libtool” by John Calcote (https://www.nostarch.com/autotools.htm). That book is from 2010 and, AFAICT, is the most up to date comprehensive description of autotools. Do not read older documentation. In particular, if a document you’re reading mentions configure.in (deprecated filename) or recursive make (now considered harmful), it’s likely outdated. ┌──────────────────────────────────────────────────────────────────────────────┐ │ changes │ └──────────────────────────────────────────────────────────────────────────────┘ This commit implements the following new functionality/changes in behavior: • We use the AX_ENABLE_BUILDDIR macro to enforce builds happening in a separate directory. This is a prerequisite for the AX_EXTEND_SRCDIR macro and building in a separate directory is common practice anyway. In case this causes any trouble when packaging i3 for your distribution, please let me know. • “make check” runs the i3 testsuite. You can still use ./testcases/complete-run.pl to get the interactive progress output. • “make distcheck” (runs testsuite on “make dist” result, tiny bit quicker feedback cycle than waiting for the travis build to catch the issue). • “make uninstall” (occasionally requested by users who compile from source) • “make” will build manpages/docs by default if the tools are installed. Conversely, manpages/docs are not tried to be built for users who don’t want to install all these dependencies to get started hacking on i3. • non-release builds will enable address sanitizer by default. Use the --disable-sanitizers configure option to turn off all sanitizers, and see --help for available sanitizers. • Support for pre-compiled headers (PCH) has been dropped for now in the interest of simplicitly. Maybe we can re-add it later. • coverage reports are now generated using “make check-code-coverage”, which requires specifying --enable-code-coverage when calling configure. ┌──────────────────────────────────────────────────────────────────────────────┐ │ build system feature parity/testing │ └──────────────────────────────────────────────────────────────────────────────┘ In addition to what’s described above, I tested the following features: • “make install” installs the same files (plus documentation and manpages) cd i3-old && make install PREFIX=/tmp/inst/old cd i3-new && ./configure --prefix=/tmp/inst/new cd /tmp/inst (cd old && for f in $(find); do [ -e "../new/$f" ] || echo "$f missing"; done) • make dist generates a tarball which includes the same files cd i3-old && make dist cd i3-new/x86_64-pc-linux-gnu && make dist colordiff -u <(tar tf i3-old/i3-4.12.tar.bz2 | sort) \ <(tar tf i3-new/x86_64-pc-linux-gnu/i3-4.12.tar.gz | sort) There are some expected differences: • Some files have been renamed (e.g. the new etc/ and share/ subdirectories) • Some files will now be generated at build-time, so only their corresponding .in file is shipped (e.g. testcases/complete-run.pl) • The generated parser files are shipped in the dist tarball (they only depend on the parser-specs/* files, not on the target system) • autotools infrastructure is shipped (e.g. “configure”, “missing”, etc.) • DLOG and ELOG statements still produce the same file name in logfiles • Listing source code in gdb still works. • gdb backtraces contain the i3-<version> path component • release.sh still works • version embedding 1. git checkout shows “4.12-136-gf720023 (2016-10-10, branch "autotools")” 2. tarball of a git version shows “4.12-non-git” 3. release tarball shows 4.13 • debug mode is enabled by default for non-release builds • enabling verbose builds via V=1 ┌──────────────────────────────────────────────────────────────────────────────┐ │ speed │ └──────────────────────────────────────────────────────────────────────────────┘ There is no noticeable difference in compilation speed itself (of binaries, documentation and manpages): i3-old $ time make all docs mans -j8 make all docs mans -j8 28.92s user 2.15s system 640% cpu 4.852 total i3-new $ time make -j8 make -j8 27.08s user 1.92s system 620% cpu 4.669 total In terms of one-time costs: configuring the build system (../configure) takes about 2.7s on my machine, generating the build system (autoreconf -fi) takes about 3.1s on my machine. ┌──────────────────────────────────────────────────────────────────────────────┐ │ m4 macros │ └──────────────────────────────────────────────────────────────────────────────┘ All files in m4/ have been copied from the autoconf-archive package in version b6aeb1988f4b6c78bf39d97b6c4f6e1d594d59b9 and should be updated whenever they change. This commit has been tested with autoconf 2.69 and automake 1.15.
2016-10-07 13:48:26 +02:00
# Checks for programs.
AC_PROG_AWK
AC_PROG_CPP
AC_PROG_INSTALL
AC_PROG_MAKE_SET
AC_PROG_RANLIB
AC_PROG_LN_S
configure.ac: add conditionals for building docs/mans fixes #3378
2018-10-07 20:09:35 +02:00
AC_ARG_ENABLE(docs,
AS_HELP_STRING(
[--disable-docs],
[disable building documentation]),
[ax_docs=$enableval],
[ax_docs=yes])
AC_ARG_ENABLE(mans,
AS_HELP_STRING(
[--disable-mans],
[disable building manual pages]),
[ax_mans=$enableval],
[ax_mans=yes])
AS_IF([test x$ax_docs = xyes || test x$ax_mans = xyes], [
AC_PATH_PROG([PATH_ASCIIDOC], [asciidoc])
])
AS_IF([test x$ax_mans = xyes], [
AC_PATH_PROG([PATH_XMLTO], [xmlto])
AC_PATH_PROG([PATH_POD2MAN], [pod2man])
])
AM_CONDITIONAL([BUILD_MANS], [test x$ax_mans = xyes && test x$PATH_ASCIIDOC != x && test x$PATH_XMLTO != x && test x$PATH_POD2MAN != x])
AM_CONDITIONAL([BUILD_DOCS], [test x$ax_docs = xyes && test x$PATH_ASCIIDOC != x])
Switch to autotools (GNU build system) This commit probably comes as a surprise to some, given that one of i3’s explicitly stated goals used to be “Do not use programs such as autoconf/automake for configuration and creating unreadable/broken makefiles”. I phrased this goal over 7 years ago, based largely on a grudge that I inherited, which — as I’ve realized in the meantime — was largely held against FOSS in general, and not actually nuanced criticism of autotools. In the meantime, I have come to realize that the knee-jerk reaction of “I could do this better!” (i.e. writing our own build system in this particular case) is usually misguided, and nowadays I strongly suggest trying hard to fix the existing system for the benefit of all existing and future users. Further, I recently got to experience the other side of the coin, as I packaged a new version of FreeRADIUS for Debian, which at the time of writing used autoconf in combination with boilermake, a custom make-based build system that only FreeRADIUS uses. Understanding the build system enough to fix issues and enable parallel compilation took me an entire day. That time is time which potentially every downstream maintainer needs to invest, and the resulting knowledge cannot be applied to any other project. Hence, I believe it’s a good idea switch i3 to autotools. Yes, it might be that particular features were easier to implement/understand in our custom Makefiles, and there might be individuals who have an easier time reading through our custom Makefiles than learning autotools. All of these considerations are outweighed by the benefits we get from using the same build system as literally thousands of other FOSS software packages. Aside from these somewhat philosophical considerations, there’s also practical improvements which this change brings us. See the “changes” section below. ┌──────────────────────────────────────────────────────────────────────────────┐ │ new workflow │ └──────────────────────────────────────────────────────────────────────────────┘ You can now build i3 like you build any other software package which uses autotools. Here’s a memory refresher: autoreconf -fi mkdir -p build && cd build ../configure make -j8 (The autoreconf -fi step is unnecessary if you are building from a release tarball, but shouldn’t hurt either.) ┌──────────────────────────────────────────────────────────────────────────────┐ │ recommended reading │ └──────────────────────────────────────────────────────────────────────────────┘ I very much recommend reading “A Practitioner's Guide to GNU Autoconf, Automake, and Libtool” by John Calcote (https://www.nostarch.com/autotools.htm). That book is from 2010 and, AFAICT, is the most up to date comprehensive description of autotools. Do not read older documentation. In particular, if a document you’re reading mentions configure.in (deprecated filename) or recursive make (now considered harmful), it’s likely outdated. ┌──────────────────────────────────────────────────────────────────────────────┐ │ changes │ └──────────────────────────────────────────────────────────────────────────────┘ This commit implements the following new functionality/changes in behavior: • We use the AX_ENABLE_BUILDDIR macro to enforce builds happening in a separate directory. This is a prerequisite for the AX_EXTEND_SRCDIR macro and building in a separate directory is common practice anyway. In case this causes any trouble when packaging i3 for your distribution, please let me know. • “make check” runs the i3 testsuite. You can still use ./testcases/complete-run.pl to get the interactive progress output. • “make distcheck” (runs testsuite on “make dist” result, tiny bit quicker feedback cycle than waiting for the travis build to catch the issue). • “make uninstall” (occasionally requested by users who compile from source) • “make” will build manpages/docs by default if the tools are installed. Conversely, manpages/docs are not tried to be built for users who don’t want to install all these dependencies to get started hacking on i3. • non-release builds will enable address sanitizer by default. Use the --disable-sanitizers configure option to turn off all sanitizers, and see --help for available sanitizers. • Support for pre-compiled headers (PCH) has been dropped for now in the interest of simplicitly. Maybe we can re-add it later. • coverage reports are now generated using “make check-code-coverage”, which requires specifying --enable-code-coverage when calling configure. ┌──────────────────────────────────────────────────────────────────────────────┐ │ build system feature parity/testing │ └──────────────────────────────────────────────────────────────────────────────┘ In addition to what’s described above, I tested the following features: • “make install” installs the same files (plus documentation and manpages) cd i3-old && make install PREFIX=/tmp/inst/old cd i3-new && ./configure --prefix=/tmp/inst/new cd /tmp/inst (cd old && for f in $(find); do [ -e "../new/$f" ] || echo "$f missing"; done) • make dist generates a tarball which includes the same files cd i3-old && make dist cd i3-new/x86_64-pc-linux-gnu && make dist colordiff -u <(tar tf i3-old/i3-4.12.tar.bz2 | sort) \ <(tar tf i3-new/x86_64-pc-linux-gnu/i3-4.12.tar.gz | sort) There are some expected differences: • Some files have been renamed (e.g. the new etc/ and share/ subdirectories) • Some files will now be generated at build-time, so only their corresponding .in file is shipped (e.g. testcases/complete-run.pl) • The generated parser files are shipped in the dist tarball (they only depend on the parser-specs/* files, not on the target system) • autotools infrastructure is shipped (e.g. “configure”, “missing”, etc.) • DLOG and ELOG statements still produce the same file name in logfiles • Listing source code in gdb still works. • gdb backtraces contain the i3-<version> path component • release.sh still works • version embedding 1. git checkout shows “4.12-136-gf720023 (2016-10-10, branch "autotools")” 2. tarball of a git version shows “4.12-non-git” 3. release tarball shows 4.13 • debug mode is enabled by default for non-release builds • enabling verbose builds via V=1 ┌──────────────────────────────────────────────────────────────────────────────┐ │ speed │ └──────────────────────────────────────────────────────────────────────────────┘ There is no noticeable difference in compilation speed itself (of binaries, documentation and manpages): i3-old $ time make all docs mans -j8 make all docs mans -j8 28.92s user 2.15s system 640% cpu 4.852 total i3-new $ time make -j8 make -j8 27.08s user 1.92s system 620% cpu 4.669 total In terms of one-time costs: configuring the build system (../configure) takes about 2.7s on my machine, generating the build system (autoreconf -fi) takes about 3.1s on my machine. ┌──────────────────────────────────────────────────────────────────────────────┐ │ m4 macros │ └──────────────────────────────────────────────────────────────────────────────┘ All files in m4/ have been copied from the autoconf-archive package in version b6aeb1988f4b6c78bf39d97b6c4f6e1d594d59b9 and should be updated whenever they change. This commit has been tested with autoconf 2.69 and automake 1.15.
2016-10-07 13:48:26 +02:00
AM_PROG_AR
AX_FLAGS_WARN_ALL
AX_CHECK_COMPILE_FLAG([-Wunused-value], [AX_APPEND_FLAG([-Wunused-value], [AM_CFLAGS])])
AC_SUBST(AM_CFLAGS)
# Checks for header files.
AC_CHECK_HEADERS([fcntl.h float.h inttypes.h limits.h locale.h netinet/in.h paths.h stddef.h stdint.h stdlib.h string.h sys/param.h sys/socket.h sys/time.h unistd.h], , [AC_MSG_FAILURE([cannot find the $ac_header header, which i3 requires])])
generate asciidoc.conf via autoconf …instead of updating it in release.sh.
2016-10-16 17:23:51 +02:00
AC_CONFIG_FILES([Makefile testcases/lib/i3test.pm man/asciidoc.conf])
Switch to autotools (GNU build system) This commit probably comes as a surprise to some, given that one of i3’s explicitly stated goals used to be “Do not use programs such as autoconf/automake for configuration and creating unreadable/broken makefiles”. I phrased this goal over 7 years ago, based largely on a grudge that I inherited, which — as I’ve realized in the meantime — was largely held against FOSS in general, and not actually nuanced criticism of autotools. In the meantime, I have come to realize that the knee-jerk reaction of “I could do this better!” (i.e. writing our own build system in this particular case) is usually misguided, and nowadays I strongly suggest trying hard to fix the existing system for the benefit of all existing and future users. Further, I recently got to experience the other side of the coin, as I packaged a new version of FreeRADIUS for Debian, which at the time of writing used autoconf in combination with boilermake, a custom make-based build system that only FreeRADIUS uses. Understanding the build system enough to fix issues and enable parallel compilation took me an entire day. That time is time which potentially every downstream maintainer needs to invest, and the resulting knowledge cannot be applied to any other project. Hence, I believe it’s a good idea switch i3 to autotools. Yes, it might be that particular features were easier to implement/understand in our custom Makefiles, and there might be individuals who have an easier time reading through our custom Makefiles than learning autotools. All of these considerations are outweighed by the benefits we get from using the same build system as literally thousands of other FOSS software packages. Aside from these somewhat philosophical considerations, there’s also practical improvements which this change brings us. See the “changes” section below. ┌──────────────────────────────────────────────────────────────────────────────┐ │ new workflow │ └──────────────────────────────────────────────────────────────────────────────┘ You can now build i3 like you build any other software package which uses autotools. Here’s a memory refresher: autoreconf -fi mkdir -p build && cd build ../configure make -j8 (The autoreconf -fi step is unnecessary if you are building from a release tarball, but shouldn’t hurt either.) ┌──────────────────────────────────────────────────────────────────────────────┐ │ recommended reading │ └──────────────────────────────────────────────────────────────────────────────┘ I very much recommend reading “A Practitioner's Guide to GNU Autoconf, Automake, and Libtool” by John Calcote (https://www.nostarch.com/autotools.htm). That book is from 2010 and, AFAICT, is the most up to date comprehensive description of autotools. Do not read older documentation. In particular, if a document you’re reading mentions configure.in (deprecated filename) or recursive make (now considered harmful), it’s likely outdated. ┌──────────────────────────────────────────────────────────────────────────────┐ │ changes │ └──────────────────────────────────────────────────────────────────────────────┘ This commit implements the following new functionality/changes in behavior: • We use the AX_ENABLE_BUILDDIR macro to enforce builds happening in a separate directory. This is a prerequisite for the AX_EXTEND_SRCDIR macro and building in a separate directory is common practice anyway. In case this causes any trouble when packaging i3 for your distribution, please let me know. • “make check” runs the i3 testsuite. You can still use ./testcases/complete-run.pl to get the interactive progress output. • “make distcheck” (runs testsuite on “make dist” result, tiny bit quicker feedback cycle than waiting for the travis build to catch the issue). • “make uninstall” (occasionally requested by users who compile from source) • “make” will build manpages/docs by default if the tools are installed. Conversely, manpages/docs are not tried to be built for users who don’t want to install all these dependencies to get started hacking on i3. • non-release builds will enable address sanitizer by default. Use the --disable-sanitizers configure option to turn off all sanitizers, and see --help for available sanitizers. • Support for pre-compiled headers (PCH) has been dropped for now in the interest of simplicitly. Maybe we can re-add it later. • coverage reports are now generated using “make check-code-coverage”, which requires specifying --enable-code-coverage when calling configure. ┌──────────────────────────────────────────────────────────────────────────────┐ │ build system feature parity/testing │ └──────────────────────────────────────────────────────────────────────────────┘ In addition to what’s described above, I tested the following features: • “make install” installs the same files (plus documentation and manpages) cd i3-old && make install PREFIX=/tmp/inst/old cd i3-new && ./configure --prefix=/tmp/inst/new cd /tmp/inst (cd old && for f in $(find); do [ -e "../new/$f" ] || echo "$f missing"; done) • make dist generates a tarball which includes the same files cd i3-old && make dist cd i3-new/x86_64-pc-linux-gnu && make dist colordiff -u <(tar tf i3-old/i3-4.12.tar.bz2 | sort) \ <(tar tf i3-new/x86_64-pc-linux-gnu/i3-4.12.tar.gz | sort) There are some expected differences: • Some files have been renamed (e.g. the new etc/ and share/ subdirectories) • Some files will now be generated at build-time, so only their corresponding .in file is shipped (e.g. testcases/complete-run.pl) • The generated parser files are shipped in the dist tarball (they only depend on the parser-specs/* files, not on the target system) • autotools infrastructure is shipped (e.g. “configure”, “missing”, etc.) • DLOG and ELOG statements still produce the same file name in logfiles • Listing source code in gdb still works. • gdb backtraces contain the i3-<version> path component • release.sh still works • version embedding 1. git checkout shows “4.12-136-gf720023 (2016-10-10, branch "autotools")” 2. tarball of a git version shows “4.12-non-git” 3. release tarball shows 4.13 • debug mode is enabled by default for non-release builds • enabling verbose builds via V=1 ┌──────────────────────────────────────────────────────────────────────────────┐ │ speed │ └──────────────────────────────────────────────────────────────────────────────┘ There is no noticeable difference in compilation speed itself (of binaries, documentation and manpages): i3-old $ time make all docs mans -j8 make all docs mans -j8 28.92s user 2.15s system 640% cpu 4.852 total i3-new $ time make -j8 make -j8 27.08s user 1.92s system 620% cpu 4.669 total In terms of one-time costs: configuring the build system (../configure) takes about 2.7s on my machine, generating the build system (autoreconf -fi) takes about 3.1s on my machine. ┌──────────────────────────────────────────────────────────────────────────────┐ │ m4 macros │ └──────────────────────────────────────────────────────────────────────────────┘ All files in m4/ have been copied from the autoconf-archive package in version b6aeb1988f4b6c78bf39d97b6c4f6e1d594d59b9 and should be updated whenever they change. This commit has been tested with autoconf 2.69 and automake 1.15.
2016-10-07 13:48:26 +02:00
AC_CONFIG_FILES([testcases/complete-run.pl], [chmod +x testcases/complete-run.pl])
# Enable address sanitizer for non-release builds. The performance hit is a
# 50% increase of wallclock time for the testsuite on my machine.
if test x$is_release = xyes; then
default_sanitizers=
else
default_sanitizers=address
fi
AX_SANITIZERS(, [$default_sanitizers], [AC_DEFINE([I3_ASAN_ENABLED], [], [Enable ASAN])])
AC_OUTPUT
if test -z "${BUILD_DOCS_TRUE}"; then
print_BUILD_DOCS=yes
else
print_BUILD_DOCS=no
fi
if test -z "${BUILD_MANS_TRUE}"; then
print_BUILD_MANS=yes
else
print_BUILD_MANS=no
fi
fix auto exclude in-work-tree build dirs updates: -- configure: add build directory to gitignore #2543 -- https://github.com/i3/i3/pull/2543
2017-01-10 01:43:38 +01:00
in_git_worktree=`git rev-parse --is-inside-work-tree 2>/dev/null`
fix conditional in configure script
2017-01-11 03:48:59 +01:00
if [[ "$in_git_worktree" = "true" ]]; then
fix auto exclude in-work-tree build dirs updates: -- configure: add build directory to gitignore #2543 -- https://github.com/i3/i3/pull/2543
2017-01-10 01:43:38 +01:00
git_dir=`git rev-parse --git-dir 2>/dev/null`
configure: add build directory to gitignore (#2543)
2016-11-07 20:49:26 +01:00
srcdir=`dirname "$git_dir"`
exclude_dir=`pwd | sed "s,^$srcdir,,g"`
if ! grep -q "^$exclude_dir" "$git_dir/info/exclude"; then
echo "$exclude_dir" >> "$git_dir/info/exclude"
fi
fi
Switch to autotools (GNU build system) This commit probably comes as a surprise to some, given that one of i3’s explicitly stated goals used to be “Do not use programs such as autoconf/automake for configuration and creating unreadable/broken makefiles”. I phrased this goal over 7 years ago, based largely on a grudge that I inherited, which — as I’ve realized in the meantime — was largely held against FOSS in general, and not actually nuanced criticism of autotools. In the meantime, I have come to realize that the knee-jerk reaction of “I could do this better!” (i.e. writing our own build system in this particular case) is usually misguided, and nowadays I strongly suggest trying hard to fix the existing system for the benefit of all existing and future users. Further, I recently got to experience the other side of the coin, as I packaged a new version of FreeRADIUS for Debian, which at the time of writing used autoconf in combination with boilermake, a custom make-based build system that only FreeRADIUS uses. Understanding the build system enough to fix issues and enable parallel compilation took me an entire day. That time is time which potentially every downstream maintainer needs to invest, and the resulting knowledge cannot be applied to any other project. Hence, I believe it’s a good idea switch i3 to autotools. Yes, it might be that particular features were easier to implement/understand in our custom Makefiles, and there might be individuals who have an easier time reading through our custom Makefiles than learning autotools. All of these considerations are outweighed by the benefits we get from using the same build system as literally thousands of other FOSS software packages. Aside from these somewhat philosophical considerations, there’s also practical improvements which this change brings us. See the “changes” section below. ┌──────────────────────────────────────────────────────────────────────────────┐ │ new workflow │ └──────────────────────────────────────────────────────────────────────────────┘ You can now build i3 like you build any other software package which uses autotools. Here’s a memory refresher: autoreconf -fi mkdir -p build && cd build ../configure make -j8 (The autoreconf -fi step is unnecessary if you are building from a release tarball, but shouldn’t hurt either.) ┌──────────────────────────────────────────────────────────────────────────────┐ │ recommended reading │ └──────────────────────────────────────────────────────────────────────────────┘ I very much recommend reading “A Practitioner's Guide to GNU Autoconf, Automake, and Libtool” by John Calcote (https://www.nostarch.com/autotools.htm). That book is from 2010 and, AFAICT, is the most up to date comprehensive description of autotools. Do not read older documentation. In particular, if a document you’re reading mentions configure.in (deprecated filename) or recursive make (now considered harmful), it’s likely outdated. ┌──────────────────────────────────────────────────────────────────────────────┐ │ changes │ └──────────────────────────────────────────────────────────────────────────────┘ This commit implements the following new functionality/changes in behavior: • We use the AX_ENABLE_BUILDDIR macro to enforce builds happening in a separate directory. This is a prerequisite for the AX_EXTEND_SRCDIR macro and building in a separate directory is common practice anyway. In case this causes any trouble when packaging i3 for your distribution, please let me know. • “make check” runs the i3 testsuite. You can still use ./testcases/complete-run.pl to get the interactive progress output. • “make distcheck” (runs testsuite on “make dist” result, tiny bit quicker feedback cycle than waiting for the travis build to catch the issue). • “make uninstall” (occasionally requested by users who compile from source) • “make” will build manpages/docs by default if the tools are installed. Conversely, manpages/docs are not tried to be built for users who don’t want to install all these dependencies to get started hacking on i3. • non-release builds will enable address sanitizer by default. Use the --disable-sanitizers configure option to turn off all sanitizers, and see --help for available sanitizers. • Support for pre-compiled headers (PCH) has been dropped for now in the interest of simplicitly. Maybe we can re-add it later. • coverage reports are now generated using “make check-code-coverage”, which requires specifying --enable-code-coverage when calling configure. ┌──────────────────────────────────────────────────────────────────────────────┐ │ build system feature parity/testing │ └──────────────────────────────────────────────────────────────────────────────┘ In addition to what’s described above, I tested the following features: • “make install” installs the same files (plus documentation and manpages) cd i3-old && make install PREFIX=/tmp/inst/old cd i3-new && ./configure --prefix=/tmp/inst/new cd /tmp/inst (cd old && for f in $(find); do [ -e "../new/$f" ] || echo "$f missing"; done) • make dist generates a tarball which includes the same files cd i3-old && make dist cd i3-new/x86_64-pc-linux-gnu && make dist colordiff -u <(tar tf i3-old/i3-4.12.tar.bz2 | sort) \ <(tar tf i3-new/x86_64-pc-linux-gnu/i3-4.12.tar.gz | sort) There are some expected differences: • Some files have been renamed (e.g. the new etc/ and share/ subdirectories) • Some files will now be generated at build-time, so only their corresponding .in file is shipped (e.g. testcases/complete-run.pl) • The generated parser files are shipped in the dist tarball (they only depend on the parser-specs/* files, not on the target system) • autotools infrastructure is shipped (e.g. “configure”, “missing”, etc.) • DLOG and ELOG statements still produce the same file name in logfiles • Listing source code in gdb still works. • gdb backtraces contain the i3-<version> path component • release.sh still works • version embedding 1. git checkout shows “4.12-136-gf720023 (2016-10-10, branch "autotools")” 2. tarball of a git version shows “4.12-non-git” 3. release tarball shows 4.13 • debug mode is enabled by default for non-release builds • enabling verbose builds via V=1 ┌──────────────────────────────────────────────────────────────────────────────┐ │ speed │ └──────────────────────────────────────────────────────────────────────────────┘ There is no noticeable difference in compilation speed itself (of binaries, documentation and manpages): i3-old $ time make all docs mans -j8 make all docs mans -j8 28.92s user 2.15s system 640% cpu 4.852 total i3-new $ time make -j8 make -j8 27.08s user 1.92s system 620% cpu 4.669 total In terms of one-time costs: configuring the build system (../configure) takes about 2.7s on my machine, generating the build system (autoreconf -fi) takes about 3.1s on my machine. ┌──────────────────────────────────────────────────────────────────────────────┐ │ m4 macros │ └──────────────────────────────────────────────────────────────────────────────┘ All files in m4/ have been copied from the autoconf-archive package in version b6aeb1988f4b6c78bf39d97b6c4f6e1d594d59b9 and should be updated whenever they change. This commit has been tested with autoconf 2.69 and automake 1.15.
2016-10-07 13:48:26 +02:00
echo \
"--------------------------------------------------------------------------------
build configured:
AS_HELP_STRING([i3 version:], [`echo ${I3_VERSION} | sed 's,\\\\,,g'`])
AS_HELP_STRING([is release version:], [${is_release}])
AS_HELP_STRING([build manpages:], [${print_BUILD_MANS}])
AS_HELP_STRING([build docs:], [${print_BUILD_DOCS}])
AS_HELP_STRING([enable debug flags:], [${ax_enable_debug}])
AS_HELP_STRING([code coverage:], [${CODE_COVERAGE_ENABLED}])
AS_HELP_STRING([enabled sanitizers:], [${ax_enabled_sanitizers}])
To compile, run:
cd `pwd` && make -j8
--------------------------------------------------------------------------------"