All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Anopolsky <erpo41@gmail.com>
To: Christian Parpart <trapni@gentoo.org>
Cc: David Woodhouse <dwmw2@infradead.org>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs-progs: autotoolized and splitup into {libbtrfs,tools,tests}
Date: Thu, 09 Oct 2008 15:52:09 -0600	[thread overview]
Message-ID: <1223589129.7861.61.camel@telesto> (raw)
In-Reply-To: <200810091555.38509.trapni@gentoo.org>

[-- Attachment #1: Type: text/plain, Size: 2481 bytes --]

On Thu, 2008-10-09 at 15:55 +0200, Christian Parpart wrote:
> On Thursday 09 October 2008 12:45:06 David Woodhouse wrote:
> > On Thu, 2008-10-09 at 04:20 +0200, Christian Parpart wrote:
> > > this now makes use of autoconf/automake/libtool suite,
> >
> > Please, God, no.
> >
> > I will personally buy a licence for GNU make for anyone who needs one.
> 
> In that case, you shall know what license automake is under, too,
> and despite your impressions i read above, if you don't want it, fine with me, 
> but stick to reasonable facts instead of religios talk next time you press a 
> reply button.

I nearly tried to make an argument against the autotools last night.
Today, I decided that I would rather explain why I had such a visceral
reaction to the announcement and not try to convince anyone of anything.

The GNU autotools kept me out of FOSS development for the better part of
a decade.

They obviously solve a common and important problem, or they wouldn't be
so widespread. But the knowledge gap between what can be gleaned from a
"learn C" book the knowledge required to navigate a project built with
autotools is enormous. At first I thought I was alone, but when I shared
my frustration with my programming friends I found all but one had the
same problem. 

I tried reading the entire collection of autotools documentation, but
that didn't help very much. I tried installing anjuta, hoping that it
would cover up the complexity of the build process and just let me hack,
but it never seemed to work correctly.

The problem, in my opinion, is that the autotools are chock full of
solutions to problems that many programmers have not yet encountered.
Viewed through that lens, they look like cruft. And if files associated
with autoconf and automake look like cruft to someone, that's a truly
massive amount of cruft to wade through just to get started programming.

There's no way for me to tell whether bringing autotools to the btrfs
userspace code will help or hinder the project. However, I feel fairly
certain that it will exclude a large class of potential contributors
from the development process.

Maybe people are opposed to growing the btrfs development community by
incorporating programmers who are not well versed in the problems that
arise when porting software across different distributions and
platforms. Maybe only bad programmers don't like autoconf. Decide for
yourselves. :)

Cheers,
Eric


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2008-10-09 21:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-09  2:20 [PATCH] btrfs-progs: autotoolized and splitup into {libbtrfs,tools,tests} Christian Parpart
2008-10-09  5:55 ` Christoph Hellwig
2008-10-09  6:47   ` Christian Parpart
2008-10-09 10:45 ` David Woodhouse
2008-10-09 13:55   ` Christian Parpart
2008-10-09 21:52     ` Eric Anopolsky [this message]
2008-10-09 22:07       ` David Woodhouse
2008-10-10  1:01         ` Christian Parpart
2008-10-10  6:38           ` David Woodhouse

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=1223589129.7861.61.camel@telesto \
    --to=erpo41@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=trapni@gentoo.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.