linux-kernel - Re: [ANNOUNCE] util-linux-ng 2.13-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200707051730.25776.vapier@gentoo.org>
Date:	Thu, 5 Jul 2007 17:30:24 -0400
From:	Mike Frysinger <vapier@...too.org>
To:	7eggert@....de
Cc:	Nix <nix@...eri.org.uk>, Karel Zak <kzak@...hat.com>,
	List util-linux-ng <util-linux-ng@...r.kernel.org>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [ANNOUNCE] util-linux-ng 2.13-rc1

On Thursday 05 July 2007, Bodo Eggert wrote:
> Nix <nix@...eri.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

Download attachment "signature.asc " of type "application/pgp-signature" (828 bytes)