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 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
> > SH
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.
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 d
[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 an
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
[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 on
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
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.
--
R
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
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 o
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
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
> programmer
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 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 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
> sho
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 s
[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 da
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 lik
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 beca
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_
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
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 Tue, Aug 15, 2006 at 02:11:21PM -0500, Steve Greenland wrote:
> No, you don't #ifdef all the users, you write multiple versions of a a
> generic function that hides the differences, and compile the appropriate
> one. Read the reference I gave.
> Sure, you *could* do this with autoconf driving
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 t
On 14-Aug-06, 17:32 (CDT), Hendrik Sattler <[EMAIL PROTECTED]> wrote:
> Am Montag 14 August 2006 23:27 schrieb Steve Greenland:
> > 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 s
* 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.
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 bro
[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 cond
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
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
Hendrik Sattler wrote:
> You mean the difference between manpages-posix-dev (in non-free) and
> manpages-dev (in main)? The first is not proposed by Debian (I still don't
> get why anone would want to change a standards document as not changing it
> is the whole purpose of its existence.)
In order
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 incompati
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 ve
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 por
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:
> >> >
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
Am Montag 14 August 2006 23:27 schrieb Steve Greenland:
> 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.
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 por
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?
>> >
>
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
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
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?
>> >
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 myse
-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
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 problem
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 ver
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 Joe
> 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
ll wrong, of course :) ), lets go and fix
> this. The sane way is to remove cdrtools from Debian main (unstable) and
> add a free replacement, most possible a fork from the last free version
> (which had only the CDDL licensed build scripts, which can easily be
> replaced by some automa
ot follow (all wrong, of course :) ), lets go and
> fix this. The sane way is to remove cdrtools from Debian main
> (unstable) and add a free replacement, most possible a fork from the
> last free version (which had only the CDDL licensed build scripts,
> which can easily be replaced by
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 fix
this. The sane way is to remove cdrtools from
52 matches
Mail list logo
