From: Jeff Mahoney <jeffm@suse.com>
To: Miguel Sousa Filipe <miguel.filipe@gmail.com>
Cc: Chris Mason <chris.mason@oracle.com>,
Btrfs Development List <linux-btrfs@vger.kernel.org>
Subject: Re: [patch 1/5] btrfs-progs: convert to autotools
Date: Sat, 14 Jun 2008 01:22:22 -0400 [thread overview]
Message-ID: <4853558E.7070204@suse.com> (raw)
In-Reply-To: <f058a9c30806131909m177bf1d4id296afd7340af363@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Miguel Sousa Filipe wrote:
> Hi all!
>
> On Fri, Jun 13, 2008 at 9:09 PM, Jeff Mahoney <jeffm@jeffreymahoney.com> wrote:
>> This patch converts the btrfs-progs build system from a single Makefile
>> to the autotools suite.
>>
>> The advantages are:
>> Easier construction of Makefiles
>> Easier to breakout the source into separate directories for easier management
>> Easier to build shared libraries automatically
>> Automatic checking for optional libraries, like libext2fs for btrfs-convert
>> Automatic infrastructure for installing and testing
>>
>> The caveats are:
>> Opinions on autotools are... mixed.
>> make C=1 no longer works, but is replaced by make check.
>
> Please make this optional..
> I would really prefer the simple makefile that it has now..
> If the proposed advantages are a wanted feature, I would gladly try to
> supply patches for the makefile to support them..
> Just to keep it away from autotool hell.
Yeah, the one-time 10 seconds of ./configure can be annoying while it
sanity checks your system, but how is a 70-line Makefile better than a
5-line Makefile.am? While it does essentially the same thing?
Infrastructure exists for a reason.
I'm not a huge fan of autotools either. It's heavy and annoying at
times. It can be inflexible as I rediscovered while trying to make C=1
work. On the other hand, I'm not so much of a purist that I want to
commit anyone who touches the code to understanding a maze of
Makefile(s) either.
This is the next generation file system for Linux. The reality is that
there is competition from other OSes. How is it a bad thing to make
things easier for potential developers to access the code? Initially
there may be a number of shy folks who just want a library they can work
with. Yes, the library will change as things progress. Making things
like extending it and installing it easier can only be a good thing.
- -Jeff
- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iEYEARECAAYFAkhTVY4ACgkQLPWxlyuTD7Iz/wCfRxoHAxGZbSk6aPgrO5IRjtpZ
TxoAnih5zTXfgq6QLUrNtQwJkG4I4e1G
=flaT
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2008-06-14 5:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-13 20:09 [patch 0/5] btrfs-progs: Create libbtrfs and package it up Jeff Mahoney
2008-06-13 20:09 ` [patch 1/5] btrfs-progs: convert to autotools Jeff Mahoney
2008-06-14 2:09 ` Miguel Sousa Filipe
2008-06-14 5:22 ` Jeff Mahoney [this message]
2008-06-14 6:10 ` Dongjun Shin
2008-06-14 6:38 ` Joe Peterson
2008-06-13 20:09 ` [patch 2/5] btrfs-progs: Test for sparse support in configure Jeff Mahoney
2008-06-13 20:09 ` [patch 3/5] btrfs-progs: Restructure code layout, create libbtrfs Jeff Mahoney
2008-06-13 20:09 ` [patch 4/5] btrfs-progs: Add RPM spec file support Jeff Mahoney
2008-06-13 20:09 ` [patch 5/5] btrfs-progs: Script to restructure the source as needed by patch 3 Jeff Mahoney
2008-06-13 20:29 ` [patch 0/5] btrfs-progs: Create libbtrfs and package it up Christoph Hellwig
2008-06-13 17:17 ` Jeff Mahoney
-- strict thread matches above, loose matches on Subject: below --
2008-07-16 12:00 [patch 1/5] btrfs-progs: convert to autotools Kai Moonbourn
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=4853558E.7070204@suse.com \
--to=jeffm@suse.com \
--cc=chris.mason@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=miguel.filipe@gmail.com \
/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.