From: Karel Zak <kzak@redhat.com>
To: linux-btrfs@vger.kernel.org
Subject: btrfs-prog: improve build-system by autoconf
Date: Fri, 12 Dec 2014 13:35:14 +0100 [thread overview]
Message-ID: <1418387724-20188-1-git-send-email-kzak@redhat.com> (raw)
This is first step to make btrfs-progs build system more conventional
for userspace users and developers. All is implemented by small incremental
patches to keep things review-able.
The Makefile targets and rules are no changed, things like V=1 (verbose), C=1
(sparse) static builds, etc. still work as expected. All the changes are mostly
about $LIBS, $CFLAGS and proper libraries (uuid, blkid, lzo2, ..) detection.
Note that there is also strange unused btrfs_convert_libs, btrfs_image_libs and
btrfs_fragments_libs variables with things like "-lgd -lpng -ljpeg -lfreetype".
I guess it's some legacy, right? I didn't touch these variables as I have no
clue about sense of this stuff.
[PATCH 01/10] btrfs-progs: add ./configure script
[PATCH 02/10] btrfs-progs: use config.h
[PATCH 03/10] btrfs-progs: use standard PACKAGE_* macros
[PATCH 04/10] btrfs-progs: use ./configure to generate version.h
[PATCH 05/10] btrfs-progs: check for build programs in ./configure
[PATCH 06/10] btrfs-progs: use paths and $*_LIBS from ./configure
[PATCH 07/10] btrfs-progs: cleanup compilation flags usage
[PATCH 08/10] btrfs-progs: clean generated files, make version.h
[PATCH 09/10] btrfs-progs: add --disable-backtrace
[PATCH 10/10] btrfs-progs: add --disable-documentation
The next possible step is automake, but I'd like merge ./configure stuff first.
Karel
next reply other threads:[~2014-12-12 12:35 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-12 12:35 Karel Zak [this message]
2014-12-12 12:35 ` [PATCH 01/10] btrfs-progs: add ./configure script Karel Zak
2014-12-12 12:35 ` [PATCH 02/10] btrfs-progs: use config.h Karel Zak
2014-12-12 12:35 ` [PATCH 03/10] btrfs-progs: use standard PACKAGE_* macros Karel Zak
2014-12-12 12:35 ` [PATCH 04/10] btrfs-progs: use ./configure to generate version.h Karel Zak
2014-12-12 12:35 ` [PATCH 05/10] btrfs-progs: check for build programs in ./configure Karel Zak
2014-12-12 12:35 ` [PATCH 06/10] btrfs-progs: use paths and $*_LIBS from ./configure Karel Zak
2014-12-12 12:35 ` [PATCH 07/10] btrfs-progs: cleanup compilation flags usage Karel Zak
2014-12-12 12:35 ` [PATCH 08/10] btrfs-progs: clean generated files, make version.h stuff more robust Karel Zak
2014-12-12 12:35 ` [PATCH 09/10] btrfs-progs: add --disable-backtrace Karel Zak
2014-12-12 12:35 ` [PATCH 10/10] btrfs-progs: add --disable-documentation Karel Zak
2014-12-17 14:07 ` btrfs-prog: improve build-system by autoconf David Sterba
2014-12-18 13:31 ` Karel Zak
2014-12-18 18:00 ` Eric Sandeen
2014-12-22 12:47 ` Koen Kooi
2015-01-16 15:26 ` Karel Zak
2015-01-28 15:38 ` David Sterba
2015-02-04 11:40 ` Karel Zak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1418387724-20188-1-git-send-email-kzak@redhat.com \
--to=kzak@redhat.com \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.