public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
* [patch 0/5] btrfs-progs: Create libbtrfs and package it up
@ 2008-06-13 20:09 Jeff Mahoney
  2008-06-13 20:09 ` [patch 1/5] btrfs-progs: convert to autotools Jeff Mahoney
                   ` (5 more replies)
  0 siblings, 6 replies; 13+ messages in thread
From: Jeff Mahoney @ 2008-06-13 20:09 UTC (permalink / raw)
  To: Chris Mason; +Cc: Btrfs Development List

Hi Chris -

Here's the patch set I mentioned earlier.

It consists of 4 patches and a script. Otherwise it'd be a lot more patches
that only move files around. The end result after running the script
is a directory tree that looks like this:

 btrfs-progs/lib
 btrfs-progs/src/debug
 btrfs-progs/src/fsck
 btrfs-progs/src/test
 btrfs-progs/src/util
 btrfs-progs/src/convert
 btrfs-progs/src/mkfs

lib contains the objects that used to be $(COMMON_OBJS), but are now
a full-fledged shared library with supporting includes to be installed
in /usr/include/btrfs. Headers are also placed in lib so that patches
indended for the kernel can also apply to the library without a lot of
effort.

* Patch 1: Converts to autotools
* Patch 2: Adds check for sparse support
* Patch 3: Creates libbtrfs and reshuffle programs to use it
* Patch 4: Creates a spec file

I know there are a lot of people out there who hate autotools. I'm not
a fan myself, but it does make the checking for optional libraries and
the generation of new ones really easy.

The spec file expects the library to exist and will create three packages:
btrfs-progs, libbtrfs, and libbtrfs-devel.

This all works for me.

-Jeff

-- 
Jeff Mahoney
SUSE Labs


^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: [patch 1/5] btrfs-progs: convert to autotools
@ 2008-07-16 12:00 Kai Moonbourn
  0 siblings, 0 replies; 13+ messages in thread
From: Kai Moonbourn @ 2008-07-16 12:00 UTC (permalink / raw)
  To: linux-btrfs

On Sat, Jun 14, 2008 at 2:22 PM, Jeff Mahoney <[EMAIL PROTECTED]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Miguel Sousa Filipe wrote:
>> Hi all!
>>
>> On Fri, Jun 13, 2008 at 9:09 PM, Jeff Mahoney <[EMAIL PROTECTED]> 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.


I definitely understand the need for support of this kind of tool
chain, but why autotools? Why not CMake or the like? CMake in
particular I'd think deserves consideration, since it was recently
adopted by the KDE folks, who have done a nice job making sure
development on it was brought up to speed for a large scale project.

Just a thought.

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2008-07-16 12:00 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox