From: Mike Frysinger <vapier@gentoo.org>
To: 7eggert@gmx.de
Cc: Nix <nix@esperi.org.uk>, Karel Zak <kzak@redhat.com>,
List util-linux-ng <util-linux-ng@vger.kernel.org>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [ANNOUNCE] util-linux-ng 2.13-rc1
Date: Thu, 5 Jul 2007 17:30:24 -0400 [thread overview]
Message-ID: <200707051730.25776.vapier@gentoo.org> (raw)
In-Reply-To: <E1I6SfW-0002XG-AM@be1.lrz>
[-- Attachment #1: Type: text/plain, Size: 2658 bytes --]
On Thursday 05 July 2007, Bodo Eggert wrote:
> Nix <nix@esperi.org.uk> wrote:
> > On 4 Jul 2007, DervishD stated:
> >> Anyway, if you don't like mobs or you just don't want to try it,
> >> that's fine, but please don't use autotools, it doesn't make much sense
> >> for a linux only project, since you will be using only the "directory
> >> choosing" part of autotools. Maybe a hand made script will help (and I
> >
> > Oh, yeah, great, another hand-rolled build system. That's *juwt* what
> > those of us who have autotools working well (with config.site's that
> > do all we need and then some) are looking forward to.
> >
> > There are advantages to standardization, you know. A *lot* of
> > autobuilders know how to make autoconf-generated configure scripts jump
> > through hoops. I was downright *happy* when util-linux was
> > autoconfiscated: I could ditch the code to handle automatic
> > configuration of yet another one-package hand-rolled build system.
>
> Standardisation is good, but autotools (as they are used) usurally isn't.
i dont see how blaming autotools for other people's misuse is relevant ...
this same exact claim could be made for just about any other build system,
simply apply 's/autotools/$some_build_system_you_wish_to_complain/'.
> It tests for the availability of a fortran compiler for a C-only project
a libtool bug that has been fixed upstream and is trivial to work around ...
you could also point out that libtool will also search for a C++ compiler in
a C-only project. the libtool stuff can probably be easily cleaned out from
util-linux completely thus negating this whole topic.
> checks the width of integers on i386 for projects not caring about that and
> fails to find installed libraries without telling how it was supposed to
> find them or how to make it find that library.
no idea what this rant is about.
> Configuring the build of an autotools program is harder than nescensary;
> if it used a config file, you could easily save it somewhere while adding
> comments on how and why you did *that* choice, and you could possibly
> use a set of default configs which you'd just include.
history shows this is a pita to maintain. every package has its own build
system and configuration file which means you have to go through the
documentation and figure out the magic incantation to get the thing to build
up the way you need.
> The Makefiles generated by autotools is a huge mess, if autotools got it
> wrong (again!), fixing them requires editing a lot of files.
this looks like a no brainer to me: dont edit generated files
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
next prev parent reply other threads:[~2007-07-05 21:28 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <8CYT9-4Ou-23@gated-at.bofh.it>
[not found] ` <8Dh9k-8lT-3@gated-at.bofh.it>
[not found] ` <8DtDz-3xC-15@gated-at.bofh.it>
2007-07-05 14:50 ` [ANNOUNCE] util-linux-ng 2.13-rc1 Bodo Eggert
2007-07-05 19:20 ` DervishD
2007-07-05 20:42 ` Nix
2007-07-05 20:55 ` Bernhard Walle
2007-07-06 6:42 ` Nix
2007-07-06 7:19 ` Mike Frysinger
2007-07-06 22:43 ` Nix
2007-07-06 6:41 ` DervishD
2007-07-06 7:17 ` Mike Frysinger
2007-07-06 10:43 ` DervishD
2007-07-06 12:17 ` Bodo Eggert
2007-07-06 12:51 ` DervishD
2007-07-05 20:36 ` Nix
2007-07-05 21:30 ` Mike Frysinger [this message]
2007-07-05 21:34 ` Nix
2007-07-05 21:47 ` Mike Frysinger
2007-07-06 0:30 ` Bryan Henderson
2007-07-06 1:16 ` Mike Frysinger
2007-07-06 16:50 ` Bryan Henderson
2007-07-03 22:11 Karel Zak
2007-07-04 8:42 ` Christoph Hellwig
2007-07-04 10:34 ` David Miller
2007-07-05 16:41 ` Mike Frysinger
2007-07-05 18:04 ` Andreas Dilger
2007-07-05 21:30 ` Karel Zak
2007-07-06 0:38 ` Matthew Wilcox
2007-07-05 23:03 ` Jeff Garzik
2007-07-06 9:01 ` Gerd Hoffmann
2007-07-06 9:16 ` Jeff Garzik
2007-07-06 19:35 ` Joel Becker
2007-07-09 7:20 ` Gerd Hoffmann
2007-07-09 20:18 ` Mike Frysinger
2007-07-04 11:11 ` Jan Engelhardt
2007-07-05 17:22 ` H. Peter Anvin
2007-07-04 17:47 ` DervishD
2007-07-05 7:01 ` Nix
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=200707051730.25776.vapier@gentoo.org \
--to=vapier@gentoo.org \
--cc=7eggert@gmx.de \
--cc=kzak@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nix@esperi.org.uk \
--cc=util-linux-ng@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox