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
|
|
|
# ===========================================================================
|
|
|
|
|
# http://www.gnu.org/software/autoconf-archive/ax_extend_srcdir.html
|
|
|
|
|
# ===========================================================================
|
|
|
|
|
#
|
|
|
|
|
# SYNOPSIS
|
|
|
|
|
#
|
|
|
|
|
# AX_EXTEND_SRCDIR
|
|
|
|
|
#
|
|
|
|
|
# DESCRIPTION
|
|
|
|
|
#
|
|
|
|
|
# The AX_EXTEND_SRCDIR macro extends $srcdir by one path component.
|
|
|
|
|
#
|
|
|
|
|
# As an example, when working in /home/michael/i3-4.12/build and calling
|
|
|
|
|
# ../configure, your $srcdir is "..". After calling AX_EXTEND_SRCDIR,
|
|
|
|
|
# $srcdir will be set to "../../i3-4.12".
|
|
|
|
|
#
|
|
|
|
|
# The result of extending $srcdir is that filenames (e.g. in the output of
|
|
|
|
|
# the "backtrace" gdb command) will include one more path component of the
|
|
|
|
|
# absolute source path. The additional path component makes it easy for
|
|
|
|
|
# users to recognize which files belong to the PACKAGE, and -- provided a
|
|
|
|
|
# dist tarball was unpacked -- which version of PACKAGE was used.
|
|
|
|
|
#
|
|
|
|
|
# As an example, in "backtrace", you will see:
|
|
|
|
|
#
|
|
|
|
|
# #0 main (argc=1, argv=0x7fffffff1fc8) at ../../i3-4.12/src/main.c:187
|
|
|
|
|
#
|
|
|
|
|
# instead of:
|
|
|
|
|
#
|
|
|
|
|
# #0 main (argc=1, argv=0x7fffffff1fc8) at ../src/main.c:187
|
|
|
|
|
#
|
|
|
|
|
# In case your code uses the __FILE__ preprocessor directive to refer to
|
|
|
|
|
# the filename of the current source file (e.g. in debug messages), using
|
|
|
|
|
# the extended path might be undesirable. For this purpose,
|
|
|
|
|
# AX_EXTEND_SRCDIR defines the output variable AX_EXTEND_SRCDIR_CPPFLAGS,
|
|
|
|
|
# which can be added to AM_CPPFLAGS in Makefile.am in order to define the
|
|
|
|
|
# preprocessor directive STRIPPED__FILE__. As an example, when compiling
|
|
|
|
|
# the file "../../i3-4.12/src/main.c", STRIPPED__FILE__ evaluates to
|
|
|
|
|
# "main.c".
|
|
|
|
|
#
|
|
|
|
|
# There are some caveats: When $srcdir is "." (i.e. when ./configure was
|
|
|
|
|
# called instead of ../configure in a separate build directory),
|
|
|
|
|
# AX_EXTEND_SRCDIR will still extend $srcdir, but the intended effect will
|
|
|
|
|
# not be achieved because of the way automake specifies file paths:
|
|
|
|
|
# automake defines COMPILE to use "`test -f '$source' || echo
|
|
|
|
|
# '\$(srcdir)/'`$source" in order to prefer files in the current directory
|
|
|
|
|
# over specifying $srcdir explicitly.
|
|
|
|
|
#
|
|
|
|
|
# The AX_EXTEND_SRCDIR author is not aware of any way to influence this
|
|
|
|
|
# automake behavior. Patches very welcome.
|
|
|
|
|
#
|
|
|
|
|
# To work around this issue, you can use AX_ENABLE_BUILDDIR i.e. by adding
|
|
|
|
|
# the following code to configure.ac:
|
|
|
|
|
#
|
|
|
|
|
# AX_ENABLE_BUILDDIR
|
|
|
|
|
# dnl ...
|
|
|
|
|
# AX_EXTEND_SRCDIR
|
|
|
|
|
#
|
|
|
|
|
# Then also add this bit to Makefile.am (if you wish to use
|
|
|
|
|
# STRIPPED__FILE__ in your code):
|
|
|
|
|
#
|
|
|
|
|
# AM_CPPFLAGS = @AX_EXTEND_SRCDIR_CPPFLAGS@
|
|
|
|
|
#
|
|
|
|
|
# LICENSE
|
|
|
|
|
#
|
|
|
|
|
# Copyright (c) 2016 Michael Stapelberg <michael@i3wm.org>
|
|
|
|
|
#
|
|
|
|
|
# Copying and distribution of this file, with or without modification, are
|
|
|
|
|
# permitted in any medium without royalty provided the copyright notice
|
|
|
|
|
# and this notice are preserved. This file is offered as-is, without any
|
|
|
|
|
# warranty.
|
|
|
|
|
|
|
|
|
|
#serial 3
|
|
|
|
|
|
|
|
|
|
AC_DEFUN([AX_EXTEND_SRCDIR],
|
|
|
|
|
[dnl
|
|
|
|
|
AS_CASE([$srcdir],
|
2016-11-09 22:37:21 +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
|
|
|
[
|
|
|
|
|
# pwd -P is specified in IEEE 1003.1 from 2004
|
|
|
|
|
as_dir=`cd "$srcdir" && pwd -P`
|
|
|
|
|
as_base=`AS_BASENAME([$as_dir])`
|
|
|
|
|
srcdir=${srcdir}/../${as_base}
|
|
|
|
|
|
|
|
|
|
AC_SUBST([AX_EXTEND_SRCDIR_CPPFLAGS], ["-DSTRIPPED__FILE__=AS_ESCAPE([\"$$(basename $<)\"])"])
|
|
|
|
|
])
|
|
|
|
|
])dnl AX_EXTEND_SRCDIR
|