On Monday 09 July 2007, Gerd Hoffmann wrote:
> Joel Becker wrote:
> > And if you think that all packages should Just Work on all
> > Linuxen, with out any build-time detection, try determining the
> > differing udev layouts of FC6, FC7, Debian, Ubuntu, SuSE9, SuSE10, etc.
>
> s/build/run/ time
Joel Becker wrote:
> On Fri, Jul 06, 2007 at 11:01:07AM +0200, Gerd Hoffmann wrote:
>> And the 10% where it doesn't work it is a real pain to figure what goes
>> wrong due to the completely unreadable Makefiles generated by autotools.
>> After all they are not Makefiles, they are shellscripts embe
On 6 Jul 2007, Mike Frysinger spake thusly:
> On Friday 06 July 2007, Nix wrote:
>> On 5 Jul 2007, Bernhard Walle stated:
>> >While cmake itself isn't the problem,
>> > often, it also depends on the version of cmake that is installed. The
>> > good idea about auto*
On Fri, Jul 06, 2007 at 11:01:07AM +0200, Gerd Hoffmann wrote:
> And the 10% where it doesn't work it is a real pain to figure what goes
> wrong due to the completely unreadable Makefiles generated by autotools.
> After all they are not Makefiles, they are shellscripts embedded into
> Makefiles.
>the
>maintainers of util-linux have well versed autotool people at their
disposal,
>so i really dont see this as being worrisome.
As long as that is true, I agree that the fact that so many autotool
packages don't work well is irrelevant.
However, I think the difficulty of using autotools (I
Hi Bodo :)
* Bodo Eggert <[EMAIL PROTECTED]> dixit:
> On Thu, 5 Jul 2007, DervishD wrote:
> > * Bodo Eggert <[EMAIL PROTECTED]> dixit:
>
> > > Standardisation is good, but autotools (as they are used) usurally isn't.
> >
> > Usually, by picking other's project configure.in and tweak bl
On Thu, 5 Jul 2007, DervishD wrote:
> * Bodo Eggert <[EMAIL PROTECTED]> dixit:
> > Standardisation is good, but autotools (as they are used) usurally isn't.
>
> Usually, by picking other's project configure.in and tweak blindly.
If it were that easy to write a correct automake script, peopl
Hi Mike :)
* Mike Frysinger <[EMAIL PROTECTED]> dixit:
> On Friday 06 July 2007, DervishD wrote:
> > I really like the spirit of CMake. Of course, it adds a dependency,
> > but IMHO is much safer to depend on CMake being installed (or Perl, for
> > that matter) than to depend on a shell.
Gerd Hoffmann wrote:
Jeff Garzik wrote:
Christoph Hellwig wrote:
And this is really dumb. autotools is a completely pain in the ass and
not useful at all for linux-only tools.
A myth. It is quite useful for packagers, because of the high Just
Works(tm) factor. After porting an entire across
Jeff Garzik wrote:
> Christoph Hellwig wrote:
>> And this is really dumb. autotools is a completely pain in the ass and
>> not useful at all for linux-only tools.
>
> A myth. It is quite useful for packagers, because of the high Just
> Works(tm) factor. After porting an entire across several re
On Friday 06 July 2007, Nix wrote:
> On 5 Jul 2007, Bernhard Walle stated:
> >While cmake itself isn't the problem,
> > often, it also depends on the version of cmake that is installed. The
> > good idea about auto* tools is the idea that you don't need to install
>
On Friday 06 July 2007, DervishD wrote:
> I really like the spirit of CMake. Of course, it adds a dependency,
> but IMHO is much safer to depend on CMake being installed (or Perl, for
> that matter) than to depend on a shell. Every shell out there seems to
> do things on its own, and apart from
On 5 Jul 2007, Bernhard Walle stated:
> * Nix <[EMAIL PROTECTED]> [2007-07-05 22:42]:
>>
>> My only real grouch with cmake is that the authors have invented a
>> language with so bloody many capital letters in it.
>
> The real problem I see with cmake is that you need to have cmake
> installed o
Hi Nix :)
* Nix <[EMAIL PROTECTED]> dixit:
> On 5 Jul 2007, DervishD spake thusly:
> >> 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, a
On Thursday 05 July 2007, Bryan Henderson wrote:
> >i dont see how blaming autotools for other people's misuse is relevant
>
> Here's how other people's misuse of the tool can be relevant to the choice
> of the tool: some tools are easier to use right than others. Probably the
> easiest thing to u
On Thu, Jul 05, 2007 at 11:30:20PM +0200, Karel Zak wrote:
> > > > The package build system is now based on autotools. The build system
> > > > supports separate CFLAGS and LDFLAGS for suid programs (SUID_CFLAGS,
> > > > SUID_LDFLAGS). For more details see the README file
> > >
> > > And this i
>i dont see how blaming autotools for other people's misuse is relevant
Here's how other people's misuse of the tool can be relevant to the choice
of the tool: some tools are easier to use right than others. Probably the
easiest thing to use right is the system you designed and built yourself.
Christoph Hellwig wrote:
On Wed, Jul 04, 2007 at 12:11:56AM +0200, Karel Zak wrote:
The package build system is now based on autotools. The build system
supports separate CFLAGS and LDFLAGS for suid programs (SUID_CFLAGS,
SUID_LDFLAGS). For more details see the README file
And this is real
On Thursday 05 July 2007, Nix wrote:
> On 5 Jul 2007, Mike Frysinger outgrape:
> > On Thursday 05 July 2007, Bodo Eggert wrote:
> >> 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 n
On 5 Jul 2007, Mike Frysinger outgrape:
> On Thursday 05 July 2007, Bodo Eggert wrote:
>> 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
There
On Thu, Jul 05, 2007 at 12:41:59PM -0400, Mike Frysinger wrote:
> On Wednesday 04 July 2007, Christoph Hellwig wrote:
> > On Wed, Jul 04, 2007 at 12:11:56AM +0200, Karel Zak wrote:
> > > mount(8) doesn't include filesystem detection code anymore. You
> > > have to compile --with-fsprobe={blkid,vo
On Thursday 05 July 2007, Bodo Eggert wrote:
> Nix <[EMAIL PROTECTED]> 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, sin
* Nix <[EMAIL PROTECTED]> [2007-07-05 22:42]:
>
> My only real grouch with cmake is that the authors have invented a
> language with so bloody many capital letters in it.
The real problem I see with cmake is that you need to have cmake
installed on the build system. While cmake itself isn't the
On 5 Jul 2007, DervishD spake thusly:
> * Bodo Eggert <[EMAIL PROTECTED]> dixit:
>> Standardisation is good, but autotools (as they are used) usurally isn't.
>
> Usually, by picking other's project configure.in and tweak blindly.
You'd think they'd never heard of autoscan...
> My favouri
On 5 Jul 2007, Bodo Eggert outgrape:
> I'm really really happy if I read 'edit Makefile.conf and run make...'.
autobuild scripts find it a hell of a lot more annoying to edit a different
makefile for every project than to run one unchanging config.site...
It's hardly a killer, but it would be a s
Hi Bodo :)
* Bodo Eggert <[EMAIL PROTECTED]> dixit:
> Nix <[EMAIL PROTECTED]> 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
On Jul 05, 2007 12:41 -0400, Mike Frysinger wrote:
> On Wednesday 04 July 2007, Christoph Hellwig wrote:
> > Sorry, but it's really annoying to pull in a filesystem-specific devel
> > package for that. Having a library is fine, but please move the library
> > into util-linux so it's always availa
On Wednesday 04 July 2007, Christoph Hellwig wrote:
> On Wed, Jul 04, 2007 at 12:11:56AM +0200, Karel Zak wrote:
> > mount(8) doesn't include filesystem detection code anymore. You
> > have to compile --with-fsprobe={blkid,volume_id}, and libblkid
> > (e2fsprogs) or libvolume_id (udev >= v110) i
Nix <[EMAIL PROTECTED]> 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"
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 s
Hi Karel :)
* Karel Zak <[EMAIL PROTECTED]> dixit:
> The package build system is now based on autotools. The build system
> supports separate CFLAGS and LDFLAGS for suid programs (SUID_CFLAGS,
> SUID_LDFLAGS). For more details see the README file
If you want to have configurable inst
On Jul 4 2007 00:11, Karel Zak wrote:
>newgrp:
> add support for /etc/gshadow
> check result from getgrnam() more carefully
Hm, gshadow looks like it is really obsolete. (There is no such file anymore in
suse releases since a long while. Previously, gshadow was filled with all the
gro
From: Christoph Hellwig <[EMAIL PROTECTED]>
Date: Wed, 4 Jul 2007 09:42:11 +0100
> On Wed, Jul 04, 2007 at 12:11:56AM +0200, Karel Zak wrote:
> > mount(8) doesn't include filesystem detection code anymore. You
> > have to compile --with-fsprobe={blkid,volume_id}, and libblkid
> > (e2fsprogs) or
On Wed, Jul 04, 2007 at 12:11:56AM +0200, Karel Zak wrote:
> mount(8) doesn't include filesystem detection code anymore. You
> have to compile --with-fsprobe={blkid,volume_id}, and libblkid
> (e2fsprogs) or libvolume_id (udev >= v110) is required.
Sorry, but it's really annoying to pull in a fi
The first util-linux-ng 2.13 release candidate is available at
ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/v2.13/
Thanks to all who help with util-linux resuscitation:
H. Peter Anvin
Ian Kent
and contribute to this project:
Arkadiusz Miskiewicz Matthias Koeni
35 matches
Mail list logo
