From: DervishD <lkml@dervishd.net>
To: Bodo Eggert <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 21:20:02 +0200 [thread overview]
Message-ID: <20070705192002.GB11204@DervishD> (raw)
In-Reply-To: <E1I6SfW-0002XG-AM@be1.lrz>
Hi Bodo :)
* Bodo Eggert <7eggert@gmx.de> dixit:
> 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.
Usually, by picking other's project configure.in and tweak blindly.
> It tests for the availability of a fortran compiler for a C-only
> project, 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.
My favourite is when the project doesn't honor --*dir options. Or
when the project breaks badly if you put some files in different places
by using configure options... That's good standarization.
> 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.
Looks like CMake...
> I'm really really happy if I read 'edit Makefile.conf and run make...'.
Again, this looks like CMake...
I share your view entirely.
Raúl Núñez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
WARNING: multiple messages have this Message-ID (diff)
From: DervishD <lkml-lgqjDJRqdu/k1uMJSBkQmQ@public.gmane.org>
To: Bodo Eggert <7eggert-Mmb7MZpHnFY@public.gmane.org>
Cc: Nix <nix-dKoSMcxRz+Te9xe1eoZjHA@public.gmane.org>,
Karel Zak <kzak-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
List util-linux-ng
<util-linux-ng-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [ANNOUNCE] util-linux-ng 2.13-rc1
Date: Thu, 5 Jul 2007 21:20:02 +0200 [thread overview]
Message-ID: <20070705192002.GB11204@DervishD> (raw)
In-Reply-To: <E1I6SfW-0002XG-AM-xEIfeyfbjTc@public.gmane.org>
Hi Bodo :)
* Bodo Eggert <7eggert-Mmb7MZpHnFY@public.gmane.org> dixit:
> Nix <nix-dKoSMcxRz+Te9xe1eoZjHA@public.gmane.org> 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.
Usually, by picking other's project configure.in and tweak blindly.
> It tests for the availability of a fortran compiler for a C-only
> project, 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.
My favourite is when the project doesn't honor --*dir options. Or
when the project breaks badly if you put some files in different places
by using configure options... That's good standarization.
> 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.
Looks like CMake...
> I'm really really happy if I read 'edit Makefile.conf and run make...'.
Again, this looks like CMake...
I share your view entirely.
Raúl Núñez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
next prev parent reply other threads:[~2007-07-05 19:20 UTC|newest]
Thread overview: 56+ 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 14:50 ` Bodo Eggert
2007-07-05 19:20 ` DervishD [this message]
2007-07-05 19:20 ` DervishD
2007-07-05 20:42 ` Nix
2007-07-05 20:42 ` Nix
2007-07-05 20:55 ` Bernhard Walle
2007-07-05 20:55 ` Bernhard Walle
2007-07-06 6:42 ` Nix
2007-07-06 7:19 ` Mike Frysinger
2007-07-06 7:19 ` Mike Frysinger
2007-07-06 22:43 ` Nix
2007-07-06 22:43 ` Nix
2007-07-06 6:41 ` DervishD
2007-07-06 6:41 ` DervishD
2007-07-06 7:17 ` Mike Frysinger
2007-07-06 10:43 ` DervishD
2007-07-06 10:43 ` DervishD
2007-07-06 12:17 ` Bodo Eggert
2007-07-06 12:17 ` Bodo Eggert
2007-07-06 12:51 ` DervishD
2007-07-06 12:51 ` DervishD
2007-07-05 20:36 ` Nix
2007-07-05 20:36 ` Nix
2007-07-05 21:30 ` Mike Frysinger
2007-07-05 21:34 ` Nix
2007-07-05 21:47 ` Mike Frysinger
2007-07-05 21:47 ` Mike Frysinger
2007-07-06 0:30 ` Bryan Henderson
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-03 22:11 ` Karel Zak
2007-07-04 8:42 ` Christoph Hellwig
2007-07-04 8:42 ` Christoph Hellwig
2007-07-04 10:34 ` David Miller
2007-07-04 10:34 ` David Miller
2007-07-05 16:41 ` Mike Frysinger
2007-07-05 16:41 ` Mike Frysinger
2007-07-05 18:04 ` Andreas Dilger
2007-07-05 21:30 ` Karel Zak
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-06 19:35 ` Joel Becker
2007-07-09 7:20 ` Gerd Hoffmann
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=20070705192002.GB11204@DervishD \
--to=lkml@dervishd.net \
--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 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.