On Fri, Aug 18, 2006 at 01:24:06PM -0500, Steve Greenland wrote:
No sign of what it actually did, no sign of whether the answer was
yes or no. Yes, there is some stuff in there. But not always enough.
Sometimes it spits out what the compile command was, and the code used,
and sometimes it
On Friday 18 August 2006 06:56, Matthew R. Dempsky wrote:
On Thu, Aug 17, 2006 at 08:48:24PM +0300, George Danchev wrote:
So are some widespread programming languages. If you blindly follow bad
examples and bad styles you can dynamite yourself happily without even
noticing, but that does
I demand that Russ Allbery may or may not have written...
Steve Greenland [EMAIL PROTECTED] writes:
And, for example, all of a sudden (autoconf 2.5, I think) every/many
(newly generated or regenerated) configure script starting checking for
C++ compilers, Fortran compilers, etc. etc. etc.
On 17-Aug-06, 23:33 (CDT), Peter Samuelson [EMAIL PROTECTED] wrote:
[Steve Greenland]
By autoconf related problems I mean things like it suddenly
deciding it's running a cross compiler, or that stdlib.h is
missing. A lot of this kind of stuff could be improved by simply
SHOWING ME THE
Steve Greenland [EMAIL PROTECTED] writes:
On 16-Aug-06, 04:00 (CDT), Gabor Gombas [EMAIL PROTECTED] wrote:
On Tue, Aug 15, 2006 at 02:26:29PM -0500, Steve Greenland wrote:
And guess what? System tests are actually more reliable, especially
when the user tells you what the system is. You
On Tue, Aug 15, 2006 at 02:42:09AM -0500, Peter Samuelson wrote:
[Michael Poole]
On top of the default automake behavior being horribly broken, does
that make usual revision control practices horribly broken?
It really bothers me to hear people claim as a best practice that you
should
On Wed, Aug 16, 2006 at 07:11:19PM -0500, Steve Greenland wrote:
So you chose to use a function not reliably available. Sounds like bad
planning to me.
More than a year ago the plan was that we'll support Debian Sarge only.
Then a couple of weeks ago our project partner said they'll be using
On 16-Aug-06, 19:23 (CDT), Matthew Garrett [EMAIL PROTECTED] wrote:
Yeah, wanting to use functionality when it's available is always a
dreadful idea. Far better to reimplement it locally in order to ensure
that we have more copies of it to fix should there ever be any sort of
security
On 16-Aug-06, 20:23 (CDT), Miles Bader [EMAIL PROTECTED] wrote:
The main problem with your argument is that you seem to be looking at
poorly written programs that use autoconf, and jumping to the conclusion
that autoconf is the reason for the poor programming -- it's not. Bad
programmers
Steve Greenland [EMAIL PROTECTED] wrote:
On 16-Aug-06, 19:23 (CDT), Matthew Garrett [EMAIL PROTECTED] wrote:
Yeah, wanting to use functionality when it's available is always a
dreadful idea. Far better to reimplement it locally in order to ensure
that we have more copies of it to fix should
On 16-Aug-06, 20:49 (CDT), Peter Samuelson [EMAIL PROTECTED] wrote:
As for useless autoconf tests - have you looked at how autoconf is
used? You pick the tests you think you need. It's not like the system
forces you to use a certain range of obsolete baseline tests. A huge
number of test
On 17-Aug-06, 09:06 (CDT), Gabor Gombas [EMAIL PROTECTED] wrote:
On the other hand, sw with custom build systems were always a pain:
usually they had no idea how to build a shared lib on AIX,
Neither does libtool. But I can usually easily change the Makefile to
fix that problem; libtool is an
Steve Greenland [EMAIL PROTECTED] writes:
And, for example, all of a sudden (autoconf 2.5, I think) every/many
(newly generated or regenerated) configure script starting checking for
C++ compilers, Fortran compilers, etc. etc. etc. even for pure C
projects.
This is a libtool bug.
--
Russ
On Thursday 17 August 2006 19:02, Steve Greenland wrote:
On 16-Aug-06, 20:49 (CDT), Peter Samuelson [EMAIL PROTECTED] wrote:
As for useless autoconf tests - have you looked at how autoconf is
used? You pick the tests you think you need. It's not like the system
forces you to use a certain
[Wouter Verhelst]
It has nothing to do with being afraid to, but everything with not
needing to.
There's lots of things we don't _need_ to do but we do anyway, as a
matter of quality of implementation. I believe that building a package
from source is something we should do as well, if only to
On Thu, Aug 17, 2006 at 08:48:24PM +0300, George Danchev wrote:
So are some widespread programming languages. If you blindly follow bad
examples and bad styles you can dynamite yourself happily without even
noticing, but that does not make them disused or abandoned (on the contrary
some of
[Steve Greenland]
By autoconf related problems I mean things like it suddenly
deciding it's running a cross compiler, or that stdlib.h is
missing. A lot of this kind of stuff could be improved by simply
SHOWING ME THE FSCKING ERROR MESSAGES, rather than just checking the
return code and
On Tue, Aug 15, 2006 at 02:26:29PM -0500, Steve Greenland wrote:
And guess what? System tests are actually more reliable, especially
when the user tells you what the system is. You can simply flip to
compiling foo_linux.c or foo_solaris.c and go on your way.
This will never work. Real life
On 16-Aug-06, 04:00 (CDT), Gabor Gombas [EMAIL PROTECTED] wrote:
On Tue, Aug 15, 2006 at 02:26:29PM -0500, Steve Greenland wrote:
And guess what? System tests are actually more reliable, especially
when the user tells you what the system is. You can simply flip to
compiling foo_linux.c
Steve Greenland [EMAIL PROTECTED] wrote:
On 16-Aug-06, 04:00 (CDT), Gabor Gombas [EMAIL PROTECTED] wrote:
This will never work. Real life example from a couple of weeks ago: I
wrote a program that was running happily on Sarge, then somebody wanted
to build it on RHEL and failed because the
Steve Greenland [EMAIL PROTECTED] writes:
You figure out where the incompatability points are, and you write
functions to mask them. Of course the functions themselves have
#ifdefs (or some other way of controlling compilation), but you get it
*out* of your main code base.
Gee sounds like a
[Steve Greenland]
My experience is that the ones whose build instructions say edit the
makefile to pick your platform and compiler compile and work, and
when they don't, they're easy to fix. The ones that use autoconf tend
to blow up on non-Linux[1], in ways that are hard to debug and damn
[Michael Poole]
On top of the default automake behavior being horribly broken, does
that make usual revision control practices horribly broken?
It really bothers me to hear people claim as a best practice that you
should never recompile configure.ac or Makefile.am except under
controlled
On Mon, Aug 14, 2006 at 09:40:41PM -0400, Michael Poole wrote:
Wouter Verhelst writes:
In my experience, this is greatly exacerbated and perhaps even
primarily due to older versions of autotools encouraging or requiring
behavior that later versions of autotools declare to be broken.
* Steve Greenland [EMAIL PROTECTED] [060814 23:30]:
The *real* problem with the whole autotools disaster is that it promotes
a braindead idea of how to achieve portability: a #ifdef branch for
every different system (or library version, or whatever), strewn
throughout the entire codebase. Real
On 14-Aug-06, 23:35 (CDT), Nathanael Nerode [EMAIL PROTECTED] wrote:
Steve Greenland wrote:
Um, this is the exact opposite of the philosophy promoted by Autoconf since
at least version 2.0. Feature tests, not system tests. I can't speak to
other autotools.
Doesn't matter (feature tests was
Steve Greenland [EMAIL PROTECTED] writes:
And guess what? System tests are actually more reliable, especially
when the user tells you what the system is. You can simply flip to
compiling foo_linux.c or foo_solaris.c and go on your way.
If you only port to 2 or 3 different very well-defined
On 12-Aug-06, 09:09 (CDT), Jon Dowland [EMAIL PROTECTED] wrote:
At 1155391794 past the epoch, Bernd Schubert wrote:
Btw, why always the autotools while there's this nice
cmake?
I've never used cmake myself, so I can't speak for how nice
it is, but autotools (for all its problems) is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Steve Greenland wrote:
On 12-Aug-06, 09:09 (CDT), Jon Dowland [EMAIL PROTECTED] wrote:
At 1155391794 past the epoch, Bernd Schubert wrote:
Btw, why always the autotools while there's this nice
cmake?
I've never used cmake myself, so I can't
On Mon, Aug 14, 2006 at 10:58:13AM -0500, Steve Greenland wrote:
On 12-Aug-06, 09:09 (CDT), Jon Dowland [EMAIL PROTECTED] wrote:
At 1155391794 past the epoch, Bernd Schubert wrote:
Btw, why always the autotools while there's this nice
cmake?
I've never used cmake myself, so I can't
Wouter Verhelst writes:
On Mon, Aug 14, 2006 at 10:58:13AM -0500, Steve Greenland wrote:
On 12-Aug-06, 09:09 (CDT), Jon Dowland [EMAIL PROTECTED] wrote:
At 1155391794 past the epoch, Bernd Schubert wrote:
Btw, why always the autotools while there's this nice
cmake?
I've never
On Mon, Aug 14, 2006 at 09:52:01PM +0200, Wouter Verhelst wrote:
On Mon, Aug 14, 2006 at 10:58:13AM -0500, Steve Greenland wrote:
On 12-Aug-06, 09:09 (CDT), Jon Dowland [EMAIL PROTECTED] wrote:
At 1155391794 past the epoch, Bernd Schubert wrote:
Btw, why always the autotools while
On 14-Aug-06, 15:59 (CDT), Michael Poole [EMAIL PROTECTED] wrote:
Wouter Verhelst writes:
In the case of autotools, the fact is that usually it's configure.ac or
Makefile.am being horribly broken, rather than the autotools.
In my experience, this is greatly exacerbated and perhaps even
Wouter Verhelst wrote:
On Mon, Aug 14, 2006 at 10:58:13AM -0500, Steve Greenland wrote:
On 12-Aug-06, 09:09 (CDT), Jon Dowland [EMAIL PROTECTED] wrote:
At 1155391794 past the epoch, Bernd Schubert wrote:
Btw, why always the autotools while there's this nice
cmake?
I've never used
Steve Greenland [EMAIL PROTECTED] writes:
The *real* problem with the whole autotools disaster is that it promotes
a braindead idea of how to achieve portability: a #ifdef branch for
every different system (or library version, or whatever), strewn
throughout the entire codebase. Real
Am Montag 14 August 2006 23:10 schrieb Bernd Schubert:
Wouter Verhelst wrote:
If used properly, autotools usually do their job; and pretty well, too.
Just have a look here http://lwn.net/Articles/188693
KDE never used the autotools properly (I'd rather call it hacking into it),
probably
On Mon, Aug 14, 2006 at 04:59:24PM -0400, Michael Poole wrote:
Wouter Verhelst writes:
On Mon, Aug 14, 2006 at 10:58:13AM -0500, Steve Greenland wrote:
On 12-Aug-06, 09:09 (CDT), Jon Dowland [EMAIL PROTECTED] wrote:
At 1155391794 past the epoch, Bernd Schubert wrote:
Btw, why always
Steve Greenland [EMAIL PROTECTED] writes:
The *real* problem with the whole autotools disaster is that it promotes
a braindead idea of how to achieve portability: a #ifdef branch for
every different system (or library version, or whatever), strewn
throughout the entire codebase. Real
On Mon, Aug 14, 2006 at 03:53:40PM -0700, Russ Allbery wrote:
Steve Greenland [EMAIL PROTECTED] writes:
The *real* problem with the whole autotools disaster is that it promotes
a braindead idea of how to achieve portability: a #ifdef branch for
every different system (or library version,
Wouter Verhelst writes:
In my experience, this is greatly exacerbated and perhaps even
primarily due to older versions of autotools encouraging or requiring
behavior that later versions of autotools declare to be broken.
[...]
The situation is not helped when these mutually incompatible
Steve Greenland wrote:
On 14-Aug-06, 15:59 (CDT), Michael Poole [EMAIL PROTECTED] wrote:
Wouter Verhelst writes:
In the case of autotools, the fact is that usually it's configure.ac or
Makefile.am being horribly broken, rather than the autotools.
Oh yeah. Most people don't know how to
Adam Borowski [EMAIL PROTECTED] writes:
Autotools do require you to do things the way they want, indeed. And
every single autotool uses a different obscure language. Some
consistency would be good -- but, I challenge you: write something
that works better. There's a lot of deficiencies in
The fork-team can look at http://www.arklinux.org/projects/dvdrtools, a
100% free fork of cdrtools.
The SVN is inactive from 6 month, but the autotool-ization is already
done and it can write on DVDs, and probably is better than starting
another fork.
Btw, why always the autotools while
At 1155391794 past the epoch, Bernd Schubert wrote:
Btw, why always the autotools while there's this nice
cmake?
I've never used cmake myself, so I can't speak for how nice
it is, but autotools (for all its problems) is very
widespread.
The cmake build system might even get accepted by
Alle Saturday 12 August 2006 16:09, Jon Dowland ha scritto:
At 1155391794 past the epoch, Bernd Schubert wrote:
Btw, why always the autotools while there's this nice
cmake?
I've never used cmake myself, so I can't speak for how nice
it is, but autotools (for all its problems) is very
Alle Friday 11 August 2006 22:51, Joerg Jaspert ha scritto:
reassign 377109 ftp.debian.org
retitle 377109 RM: cdrtools -- RoM: non-free, license problems
thanks
Hi guys,
ok well, as JS stays with an interpretation of CDDL and GPL that the
whole world does not follow (all wrong, of course
Joerg Jaspert [EMAIL PROTECTED] writes:
reassign 377109 ftp.debian.org
retitle 377109 RM: cdrtools -- RoM: non-free, license problems
thanks
Hi guys,
ok well, as JS stays with an interpretation of CDDL and GPL that the
whole world does not follow (all wrong, of course :) ), lets go and
47 matches
Mail list logo
