All of lore.kernel.org
 help / color / mirror / Atom feed
From: Karel Zak <kzak@redhat.com>
To: dsterba@suse.cz, linux-btrfs@vger.kernel.org
Subject: Re: btrfs-prog: improve build-system by autoconf
Date: Thu, 18 Dec 2014 14:31:12 +0100	[thread overview]
Message-ID: <20141218133111.GG19904@x2.net.home> (raw)
In-Reply-To: <20141217140726.GY27601@twin.jikos.cz>

On Wed, Dec 17, 2014 at 03:07:26PM +0100, David Sterba wrote:
> On Fri, Dec 12, 2014 at 01:35:14PM +0100, Karel Zak wrote:
> > 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.
> 
> Thanks. I went through the patches and haven't found major problems. The
> changes are affecting build system and this will need a longer period
> before all distros have a chance to adapt to that, so I'm postponing it
> to 3.19.

Cool, I'll try to prepare next set of patches with automake.

BTW, I have good experience with build-system changes -- downstream
distributions (maintainers) are usually pretty flexible :-)

> > 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.
> 
> No, it's part of the macro magic. There are pattern rules that accept
> any source in the form btrfs-something.c and also pick the libraries for
> that from variable btrfs_something_libs:
> 
> btrfs-%: $(objects) $(libs) btrfs-%.o
>         @echo "    [LD]     $@"
>         $(Q)$(CC) $(CFLAGS) -o $@ $(objects) $@.o $(LDFLAGS) $(LIBS) $($(subst -,_,$@-libs))
> 
> This is for convenience, if this turns out to be hard to do with in combination
> with autotools, I don't insist on keeping it but it has simplified the Makefile
> significantly.

OK, so -ljpeg in the Makefile is just example, right?


Anyway, for these things is better to introduce extra autoconf
AC_ARG_VAR() variables, keep is empty by default and use it in
Makefile. The advantage is that the variables are documented and
visible by ./configure --help.

For example in util-linux we have many {SUID,DAEMON,SOLIB,...}_CFLAGS
and LDFLAGS for distributions that require extensions like -fPIE,
-Wl,-z,relro etc. The same is possible to do with $LIBS.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

  reply	other threads:[~2014-12-18 13:31 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-12 12:35 btrfs-prog: improve build-system by autoconf Karel Zak
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 [this message]
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=20141218133111.GG19904@x2.net.home \
    --to=kzak@redhat.com \
    --cc=dsterba@suse.cz \
    --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.