GCC releases prior to 4.5.0 don't support -std=gnu90 so btrfs-progs won't
build at all on older distros. We can detect whether the compiler
supports -std=gnu90 and fall back to -std=gnu89 if it doesn't.
AX_CHECK_COMPILE_FLAG is the right way to do this, but it depends on
autoconf 2.64. AX_GCC_VERSION has been deprecated, so we'll use that
only for earlier autoconf versions so we can drop it when we drop
support for older autoconf releases.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Commit 2e1932e6a3 (btrfs-progs: build: simplify version tracking)
started m4_chomp to strip the newlines from the version file. m4_chomp
was introduced in autoconf 2.64 but SLE11 ships with autoconf 2.63.
For purposes of just stripping the newline, m4_flatten is sufficient.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Commit 324d4c1857 (btrfs-progs: convert: Add larger device support)
introduced new dependencies on the 64-bit API provided by e2fsprogs.
That API was introduced in v1.42 (along with bigalloc).
This patch maps the following to their equivalents in e2fsprogs < 1.42.
- ext2fs_get_block_bitmap_range2
- ext2fs_inode_data_blocks2
- ext2fs_read_ext_attr2
Since we need to detect and define EXT2_FLAG_64BITS for compatibilty
anyway, it makes sense to use that to detect the older e2fsprogs instead
of defining a new flag ourselves.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
AC_PATH_PROG won't fail even if it fails to find command path.
xmlto is required for document build and we should report error
if it doesn't exist at configure time.
Signed-off-by: Tomohiro Misono <misono.tomohiro@jp.fujitsu.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The user may have specified a different version of Python than the
python3 from their $PATH (e.g., with PYTHON=/usr/bin/python3.6).
Signed-off-by: Omar Sandoval <osandov@fb.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The C libbtrfsutil library isn't very useful for scripting, so we also
want bindings for Python. Writing unit tests in Python is also much
easier than doing so in C. Only Python 3 is supported; if someone really
wants Python 2 support, they can write their own bindings. This commit
is just the scaffolding.
Signed-off-by: Omar Sandoval <osandov@fb.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Right now the pkg-config command is hard-coded in configure.ac, which may
result in build errors on system and cross environments that have prefixed
toolchains, e.g. /usr/x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu-pkg-config.
Please see the attached patch, it has been written a while ago but it seems it
hasn't been submitted for upstream inclusion.
0001-configure.ac-Consistently-use-PKG_CONFIG.txt
Submitted by Timo Gurr.
Author: Wulf C. Krueger <philantrop@exherbo.org>
Issue: #101
Signed-off-by: David Sterba <dsterba@suse.com>
We've been using asciidoc that's written in python2, which is going to
be phased out and deprecated next year. There's a replacement,
asciidoctor. Add a configure-time detection which tool is available,
update Documentation/Makefile.in.
The original asciidoc tool is still preferred as it produces slightly
better output. The file asciidoc.conf does not have a direct equivalten
in asciidoct and would need to be replaced by extension written in ruby.
The differences:
- the <literal> are not automatically underlined and are less visible in
the generated manual page, but it's still acceptable
- the inline CSS for the html output looks subjectively worse, is less
compact and colourful
Issue: #89
Signed-off-by: David Sterba <dsterba@suse.com>
There will be a plain file tracking the last released version.
The rest will be simplified to print it where needed. The version
augmented by the current git status was not working anyway since we've
switched to autoconf. The result of version.h with the potential git
status was generated at configure time, which does not mean it's
accurate regarding the git status.
Signed-off-by: David Sterba <dsterba@suse.com>
The kernel 4.14 supports zstd, for version parity the btrfs-progs now
require libzstd by default. This can still be disabled by
./configure --disable-zstd.
Signed-off-by: David Sterba <dsterba@suse.com>
Before the change configure refused to accept it's defaults explicitly:
$ ./configure --enable-convert --with-convert=ext2,reiserfs
...
configure: error: unknown tokens for --with-convert: ,
After the change both converters are enabled:
$ ./configure --enable-convert --with-convert=ext2,reiserfs
...
btrfs-convert: yes (ext2,reiserfs)
Cc: linux-btrfs@vger.kernel.org
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Signed-off-by: David Sterba <dsterba@suse.com>
Adds zstd support to the btrfs program. An optional dependency on libzstd
>= 1.0.0 is added. Autoconf accepts `--enable-zstd' or `--disable-zstd' and
defaults to detecting if libzstd is present using `pkg-config'.
The patch is also available in my fork of btrfs-progs [1], which passes
Travis-CI with the new tests. The prebuilt binary is available there.
I haven't updated Android.mk.
[1] https://github.com/terrelln/btrfs-progs/tree/devel
Signed-off-by: Nick Terrell <terrelln@fb.com>
Signed-off-by: David Sterba <dsterba@suse.com>
This patch adds support to convert reiserfs file systems in-place to btrfs.
It will convert extended attribute files to btrfs extended attributes,
translate ACLs, coalesce tails that consist of multiple items into one item,
and convert tails that are too big into indirect files.
This requires that libreiserfscore 3.6.27 be available.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
It's not really necessary to configure and regenerate Makefiles in cases
like adding a new source file. The build environment and optional
features are not affected by that.
Signed-off-by: David Sterba <dsterba@suse.com>
The FIEMAP_EXTENT_SHARED fiemap flag was introduced in 2.6.33. If the
headers do not provide the definition, the build will fail. The support
of the fiemap sharing depends on the running kernel. There are still
systems with 2.6.32 kernel headers but running newer versions.
To support such environment, don't fail build, provide own defintion of
the structure and detect if there's an old kernel in use in the relevant
command (btrfs fi du).
Reported-by: Abhay Sachan <lkp.abhay@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Prior to udev v190, there was no btrfs builtin helper. Installing it on
systems with an older udev will cause problems.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Add --with-convert[=VALUE] option to configure. Accepts ext2, auto, yes,
or no, but will be extended to more in the future. The configure-time
defines are not used in the code, ext2 is built-in unconditionally.
Signed-off-by: David Sterba <dsterba@suse.com>
The new convert framework copies code from current dumpe2fs, which uses
BIGALLOC feature introduced in e2fsprogs v1.42.
While there are a lot of enterprise distributions which are still using
v1.41 e2fsprogs, this will cause compile error for them.
This patch introduces backward compatibility for new convert framework,
by manually introduce macros for ext2 BIGALLOC feature.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
btrfs-progs build failed in CentOS 6 and 7:
#./autogen.sh
...
configure.ac:131: error: possibly undefined macro: PKG_CHECK_VAR
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
...
Seems PKG_CHECK_VAR is new in pkgconfig 0.28 (24-Jan-2013):
http://redmine.audacious-media-player.org/boards/1/topics/736
And the max available version for CentOS 7 in yum-repo and
rpmfind.net is: pkgconfig-0.27.1-4.el7
http://rpmfind.net/linux/rpm2html/search.php?query=pkgconfig&submit=Search+...&system=centos&arch=
I updated my pkgconfig to 0.30, but still failed at above error.
(Maybe it is my setting problem)
To make user in centos 6 and 7 building btrfs-progs without
more changes, we can avoid using PKG_CHECK_VAR in following
way found in:
f95ab6f939
Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Systemd's btrfs rule runs btrfs dev ready on each device
as it's discovered. The btrfs command is executed as a builtin
command via an IMPORT{builtin} rule, which means it gets
executed at rule evaluation time, not rule execution time. That
means that the device mapper links haven't been setup yet and the only
nodes that can be depended upon are /dev/dm-#. That we see
/dev/mapper/name names in /proc/mounts is only because we replace the
device name we have cached with the one passed in via mount. If
we have a multi-device file system and the primary device is removed,
the remaining devices will show /dev/dm-#. In addition, if the
udev rule is executed again by someone generating a change event (e.g.
partprobe), the names are also replaced by the /dev/dm-# names.
This patch adds a new rule that adds a run rule that calls btrfs dev
ready again using the device mapper links once they're created.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
We want to support version 1.41 due to longterm and enterprise distros,
make the check explicit.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
AC_CHECK_TOOL takes the --host option into account for cross-compiling.
Signed-off-by: Mike Gilbert <floppym@gentoo.org>
Signed-off-by: David Sterba <dsterba@suse.com>
The conversion to autotools changed the default prefix to /usr. There's
no reason to diverge. Distributions builds set prefix the /usr path and
local builds are supposed to go to /usr/local .
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=108571
Reported-by: Karl Richter <krichter722@aol.de>
Signed-off-by: David Sterba <dsterba@suse.com>
AC_ARG_ENABLE(convert) sets $enable_convert, not $enable_btrfsconvert.
Signed-off-by: Mike Gilbert <floppym@gentoo.org>
Signed-off-by: David Sterba <dsterba@suse.cz>
The PACKAGE_URL is set from optional parameter of AC_INIT starting in
autoconf 2.64. There are enterprise distros with version 2.63, we can
make the build work there easily as well.
Fixes build failure:
mkfs.c: In function ?main?:
mkfs.c:1492: error: ?PACKAGE_URL? undeclared (first use in this function)
Reported-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Keep only flags that are required to build properly, current fine
tunings are moved to the optional defaults in configure and can be
overriden by the user.
Signed-off-by: David Sterba <dsterba@suse.cz>
The expected way to define custom CFLAGS is
$ export CFLAGS=...
$ ./configure ...
the build will use them. No not override the make variables directly
from now on.
Signed-off-by: David Sterba <dsterba@suse.cz>
- define basic default CFLAGS in configure.ac, because:
* autoconf default is -g -O2, but btrfs uses -g -O1
* it's better to follow autoconf; standard way to modify
CFLAGS is to call: CFLAGS="foo bar" ./configure
- move all flags to one place in Makefile.in
- don't use AM_CFLAGS, the CFLAGS and STATIC_CFLAGS are enough
- don't mix objects and flags in $LIBS, it's more readable to
add $(libs) to make rules
Signed-off-by: Karel Zak <kzak@redhat.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
The original homemade solution is unnecessary, autotools provides better
infrastructure to generate files.
Signed-off-by: Karel Zak <kzak@redhat.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
- add ./autogen.sh script (necessary after git clean/clone)
- add ./configure.ac
- copy autotool helper scripts from automake
- modify version.sh to be usable from the configure script
- rename Makefile to Makefile.in and use basic variables from configure.ac
Signed-off-by: Karel Zak <kzak@redhat.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Jeff Mahoney
Misono Tomohiro
Omar Sandoval
David Sterba
Sergei Trofimovich
Nick Terrell
Qu Wenruo
Zhao Lei
Mike Gilbert
David Sterba
Karel Zak