All of lore.kernel.org
 help / color / mirror / Atom feed
From: Karel Zak <kzak@redhat.com>
To: dsterba@suse.cz, Anand Jain <Anand.Jain@oracle.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 2/2 v4] btrfs-progs: optimize btrfs_scan_lblkid() for multiple calls
Date: Fri, 28 Nov 2014 10:33:27 +0100	[thread overview]
Message-ID: <20141128093327.GA1994@x2.net.home> (raw)
In-Reply-To: <20141114165127.GC8614@twin.jikos.cz>

On Fri, Nov 14, 2014 at 05:51:27PM +0100, David Sterba wrote:
> On Tue, Nov 11, 2014 at 12:47:35PM +0100, Karel Zak wrote:
> >  What I see critical is missing ./configure, because it's pretty ugly
> >  to add hardcoded dependencies (e.g. libudev), there is also no checks
> >  for another libs, Makefile does not care about place where libs are
> >  installed, header files,  etc. etc.
> 
> It does, prefix and libdir are set conditionally, DESTDIR works.
> 
> >  Is there any fundamental problem with autoconf? If no, then I'm ready
> >  to send patches with some autotools stuff. Comments?
> 
> Yeah the build dependencies checks would be nice, there's no problem
> with autoconf.

 OK, I'll try to prepare something next week.

> The Makefile has been manualy crafted and supports some macro magic to
> build several binaries from one rule, static targets, quiet/verbose
> build. I want to preserve all of this so transition to automake may take
> time (or may not happen in the end).

 Just note, it's fine to expect (require) some build-system features,
 but IMHO it's bad idea to think about build system as about stable
 and always backwardly compatible interface (./configure options,
 Makefile vars, etc).

 For example for util-linux we have changed many many things in last
 (~7) years without negative feedback from downstream maintainers or
 users. IMHO more important is to follow usual conventions than assume
 that my "make FOO=bar" will work forever.

    Karel

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

      reply	other threads:[~2014-11-28  9:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-15  0:51 [PATCH 1/2] btrfs-progs: introduce btrfs_register_all_device() Anand Jain
2014-10-15  0:51 ` [PATCH 2/2] btrfs-progs: optimize btrfs_scan_lblkid() for multiple calls Anand Jain
2014-10-23  6:30   ` [PATCH 2/2 v2] " Anand Jain
2014-10-30 14:18     ` David Sterba
2014-10-31  1:38       ` Anand Jain
2014-10-31  3:19   ` [PATCH 2/2 v3] " Anand Jain
2014-10-30 14:33 ` [PATCH 1/2] btrfs-progs: introduce btrfs_register_all_device() David Sterba
2014-10-31  2:28   ` Anand Jain
2014-10-31  4:11 ` [PATCH 1/2 v4] " Anand Jain
2014-10-31  4:11   ` [PATCH 2/2 v4] btrfs-progs: optimize btrfs_scan_lblkid() for multiple calls Anand Jain
2014-10-31  9:08     ` Karel Zak
2014-10-31 11:04       ` Anand Jain
2014-11-11 11:47         ` Karel Zak
2014-11-14 16:51           ` David Sterba
2014-11-28  9:33             ` Karel Zak [this message]

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=20141128093327.GA1994@x2.net.home \
    --to=kzak@redhat.com \
    --cc=Anand.Jain@oracle.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.