Re: Remove cdrtools
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 doesn't. If you want more information you can always do bash -xv ./configure ... Hmmm, why is it checking for string.h and limits.h after it has already checked for ANSI C header files? Because whoever created configure.ac told it to do so? Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 not make them disused or abandoned (on the contrary some of them have notoriously prolonged life cycle ;-)... it just matters who is using them and how. People without the skill to program in error-prone languages are encouraged to use more idiot-proof ones instead. The human itself is prone to error, and even skilled people could make funny and hard to detect errs, based on their current mood, attitude and character if you want, which tends to be impermanent. Why isn't the same done for build frameworks? /* I rather wrote about their rŠµsemblance, not their divergence */ Probably because masses first invent and face the error-prone solution, then ascertain the fact that they are enough error-prone to be used by mortals, which could take quite long periods of time needed to accumulate that experience, and then strive to find out and learn about more robust approaches. E.g. if Ada predated C, we shouldn't see some of the human-nature based errors in UNIX, when you meant foo, but it easily turned to be bar instead ;-)... I don't believe this applies to autotools, even though beasts like scons seems to be better imho leaving lesser room to dig in errors. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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. even for pure C projects. This is a libtool bug. I'm using the following workaround for gxine (due to the browser plugin): m4_undefine([AC_PROG_CXX]) m4_defun([AC_PROG_CXX],[]) m4_undefine([AC_PROG_F77]) m4_defun([AC_PROG_F77],[]) before invoking any A[CM]*LIBTOOL*. -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Burn less waste. Use less packaging. Waste less. USE FEWER RESOURCES. I'd like to, but I have to answer all of my occupant letters. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 FSCKING ERROR MESSAGES, rather than just checking the return code and guessing. Too bad autoconf doesn't keep a log of everything configure does.[1] [1] In case you missed it, it's called 'config.log'. Amazingly enough, I knew about this. From an apache2 config.log, just 'cause it's the first one I found: configure:2533: checking whether gcc accepts -g configure:2565: checking how to run the C preprocessor configure:2966: checking for rm configure:3003: checking for mawk configure:3044: checking for a BSD compatible install configure:3097: checking whether ln -s works configure:3126: checking for ranlib configure:3192: checking for AIX configure:3216: checking for POSIXized ISC configure:3238: checking for minix/config.h configure:3291: checking for ANSI C header files configure:3409: checking for string.h configure:3409: checking for limits.h configure:3409: checking for unistd.h configure:3409: checking for sys/socket.h configure:3409: checking for pwd.h configure:3409: checking for grp.h 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 doesn't. Hmmm, why is it checking for string.h and limits.h after it has already checked for ANSI C header files? Well, this has devolved into a Yes it is/No it isn't kind of argument, and maybe that's all it can be: I don't like the autotools, because of my particular experiences with them, and others do, because of their particular experiences. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 can simply flip to compiling foo_linux.c or foo_solaris.c and go on your way. 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 UUID library on RHEL does not have uuid_unparse_lower(). So you chose to use a function not reliably available. Sounds like bad planning to me. And RHEL _is_ Linux and it is pretty heavily used in corporate environments. So instead of foo_linux.c you need foo_sarge.c, foo_etch.c, foo_rhel.c, foo_opensuse.c and probably a dozen more, which is just plainly unmanageable. No, you figure out what the base system requirement is, and write to that. I can guarantee you that there's a lot more difference between AIX and Linux than there is between RHEL 3.x and Debian sarge, not to even mention non-Unix platforms. None-the-less, code can be written that runs on all of them. 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. Then again you have code that depends on the size of variable types, the availability of header files, libaries, functions in libraries, different prototypes for functions, . Instead of finding out what all those parameters are for each system and writing an foo_system.c you can use autoconf to run reliable testcases for them and use the results to automatically adjust to the probed set of parameters. Especialy when you have optional stuff, like 'png support yes/no', then you need something to easily set the #ifdef variables. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: afraid to build from source? (was Re: Remove cdrtools)
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 never recompile configure.ac or Makefile.am except under controlled conditions. To me it is a very important philosophical point that Debian be self-hosting. That means packages should build without error from source, not just from intermediate text files like 'y.tab.c', 'configure', or 'Makefile.in' which, while arch-independent, are not particularly human-editable, and certainly not source code in the GPL sense. Using a provided 'configure' binary instead of building from source has the same problem as using any other provided binary rather than building from source. It clearly expresses a lack of confidence that the system _is_ in fact self-hosting. It tells our users, we will give you all the source code, but you'd better not modify that one configure.in source file, because we do not dare trust our tools to build it correctly. So yeah, I advocate always building packages from source, and if autoconf someday comes up with an incompatibility that causes a FTBFS somewhere, let that be reported and fixed. Not just worked around by trying to avoid running autoconf. It has nothing to do with being afraid to, but everything with not needing to. Building and testing a C program on one architecture does not necessarily mean that it will work on another, too. Differences that exist in things such as endianness, word size, signedness of default types, and other things, may mean that a C program which works perfectly on one architecture may break on another. The same isn't true for autoconf; this is written in portable POSIX shell. If it works on one architecture, it works on all of them. The output of autotools, if done with the same version, is totally deterministic. Proper use of autotools will retain that deterministic property. Proper use does include things like making sure you use at least the autotools version for which your configure.ac and/or Makefile.am was written. It also includes making sure that you do not try to do things that will work on one Linux-based architecture, but will fail horribly on another. Sure, you should verify that things still work if you run autoreconf on your source tarball, but there is no real need to build autotools output files in the build target of debian/rules if all you want to do is verify that they build properly. An extra reason not to do this is that some older versions of the autotools will not run themselves as automake-version or autoconf-version or whatnot, resulting in behaviour that is not, in fact, deterministic, since if you have more than one version of the autotools installed, the default version may very well be the wrong one. Moreover, this thread, at least to me, is more about what an upstream should do rather than what a Debian developer should do; it is not good practice as an upstream to assume that anyone else than yourself will need to run the autotools on your input files on a regular basis. You should distribute the .tar.gz (and, optionally, the .tar.bz2 if you build that too), which you produce with 'make distcheck'. If you do that, everything _will_ work for everyone else, and there will not be a need to put in backwards compatibility stuff for people using older versions of autotools. If someone does want to modify the configure.ac or whatnot, it is not unreasonable to ask that they upgrade to the most recent version. Of course, you should add things like AC_PREREQ to the right input files to make that easier, but that's a different matter. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 RHEL no matter what. So much for planning. I spend quite a bit of my life working on non-Linux platforms (as well as a variety of Linux ones). I've built *lots* of free software on these platforms. 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 near impossible to fix. A couple of years ago I used to be an AIX/Solaris admin and I had quite the opposite experiences. Installing software that used autoconf was generally painless, building the software simultaneously on 3 platforms from a common source (NFS) just worked almost always. 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, they did not support building outside of the source directory etc. In case of bugs, autoconf helps a _lot_ since you know that every build system looks the same, if you find a bug (like libtool being notoriously broken on AIX) the same bug will be present in every package and the same fix can be applied etc. On the other hand, all custom build systems had their own bugs that required a lot more time to investigate. autoconf/automake/libtool are just like many traditional UNIX tools: they are all sharp knifes which can cut you deep if you use them badly, but can also help a lot if you use them wisely. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 flaw. You can't have it both ways. Either your program *requires* the new/unusual functionality exist on the system, in which case it will never port to the systems that don't have it, or you'll have to provde a custom implementation, in which case you have the multiple implementations problem anyway. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 made a hash of it no matter what style of portability they choose. My experience is that *most* autoconf using programs are written in the bad style, because (I assume) a *lot* of people think something along the lines of my code is portable because I use autoconf. My *opinion* is a lot of that is a result of the autoconf documentation and examples. My additional experience is that debugging and fixing autoconf related problems is a real pain in the ass. 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 guessing. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 there ever be any sort of security flaw. You can't have it both ways. Either your program *requires* the new/unusual functionality exist on the system, in which case it will never port to the systems that don't have it, or you'll have to provde a custom implementation, in which case you have the multiple implementations problem anyway. Or (c), my program will take advantage of extra functionality when it's present. You seem to be asserting that this level of granularity is unacceptable, so in your model we end up with a choice between less functional software or potential screaming security misery. I think this is arbitrary and unnecessary. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 macros are provided, but nobody forces you to use them. But everybody does, to the point where it now often takes (much!) longer to run configure than to actually build the program. 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. I don't know if this is something that changed in autoconf, or something that changed in one of the higher level autotools. I don't particularly care. It's not whether or not autoconf itself requires this behavriour, it's that de-facto, *most* autotools using projects exhibit this behaviour. Probably because the examples or templates use it, and it's easier to use them unchanged than actually think about what they're doing. See, my argument is not that autconf *can't* be used in a wise manner; my argument is that it tends to lead to bad usage, widely propogated. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 disaster. There's no point in figuring out the libtool bug (somewhere in its umpty-thousand lines of sh code) and submitting a fix, since it will be broken again the next release. Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 range of obsolete baseline tests. A huge number of test macros are provided, but nobody forces you to use them. But everybody does, to the point where it now often takes (much!) longer to run configure than to actually build the program. 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. I don't know if this is something that changed in autoconf, or something that changed in one of the higher level autotools. I don't particularly care. It's not whether or not autoconf itself requires this behavriour, it's that de-facto, *most* autotools using projects exhibit this behaviour. Probably because the examples or templates use it, and it's easier to use them unchanged than actually think about what they're doing. See, my argument is not that autconf *can't* be used in a wise manner; my argument is that it tends to lead to bad usage, widely propogated. 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 them have notoriously prolonged life cycle ;-)... it just matters who is using them and how. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: afraid to build from source? (was Re: Remove cdrtools)
[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 ensure that our packages do continue to build from source, using our tools. And when I say from source, I'm using the GPL definition of source code, the preferred form for making modificatons, which I think is a pretty useful definition in general. Sure, you should verify that things still work if you run autoreconf on your source tarball, but there is no real need to build autotools output files in the build target of debian/rules if all you want to do is verify that they build properly. The same could be said for lots of other tools: bison and flex are the obvious ones, but also yodl, docbook2x and other documentation convertors. Is it reasonable to tell maintainers that every architecture-independent generated file should be built manually and shipped in the .diff.gz rather than built as part of the debian build? Moreover, this thread, at least to me, is more about what an upstream should do rather than what a Debian developer should do; it is not good practice as an upstream to assume that anyone else than yourself will need to run the autotools on your input files on a regular basis. What an upstream should do and what Debian should do are quite different things. It has long been accepted that an upstream's best practice is _not_ to require users to have autoconf installed locally - they can assume you have a compiler and make and common tools like awk, but not autoconf or flex. Debian does not have this problem. Our 'apt-get build-dep' command ensures that it is convenient for our users to use pretty much any tool we need, when rebuilding our packages. We don't _have_ to worry about providing pre-built output from autoconf, flex, bison and the like. Our build dependencies even make it easy to require a particular minimum version of any tool. In summary, I think it's important for our users to be able to build packages from source. This implies that _we_ should build from source, in order to exercise the whole toolchain, so that we know it always works. And if it's so fragile that it _doesn't_ always work ... well, then _that's_ a problem which needs to be addressed. Is the autoconf unreliability problem really so intractible that it requires a workaround of don't ever use it except in a manual process where you can test it immediately to see if it worked? Would we tolerate that same requirement in a tool like docbook2x? signature.asc Description: Digital signature
Re: Remove cdrtools
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 them have notoriously prolonged life cycle ;-)... it just matters who is using them and how. People without the skill to program in error-prone languages are encouraged to use more idiot-proof ones instead. Why isn't the same done for build frameworks? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
[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 guessing. Too bad autoconf doesn't keep a log of everything configure does.[1] [1] In case you missed it, it's called 'config.log'. signature.asc Description: Digital signature
Re: Remove cdrtools
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 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 UUID library on RHEL does not have uuid_unparse_lower(). And RHEL _is_ Linux and it is pretty heavily used in corporate environments. So instead of foo_linux.c you need foo_sarge.c, foo_etch.c, foo_rhel.c, foo_opensuse.c and probably a dozen more, which is just plainly unmanageable. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 or foo_solaris.c and go on your way. 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 UUID library on RHEL does not have uuid_unparse_lower(). So you chose to use a function not reliably available. Sounds like bad planning to me. And RHEL _is_ Linux and it is pretty heavily used in corporate environments. So instead of foo_linux.c you need foo_sarge.c, foo_etch.c, foo_rhel.c, foo_opensuse.c and probably a dozen more, which is just plainly unmanageable. No, you figure out what the base system requirement is, and write to that. I can guarantee you that there's a lot more difference between AIX and Linux than there is between RHEL 3.x and Debian sarge, not to even mention non-Unix platforms. None-the-less, code can be written that runs on all of them. 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. And yes, you could use autoconf to control those generic functions. But usually it's overkill. If you actually understand enough about where the edges of portability are, you don't need autoconf, and if you don't, autoconf doesn't help, because you waste your time checking for things that are universally available (memcpy(), string.h) and don't have clue about variances in signal handling, or why assuming char is signed is a bad idea. I spend quite a bit of my life working on non-Linux platforms (as well as a variety of Linux ones). I've built *lots* of free software on these platforms. 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 near impossible to fix. Steve [1] Prior to the widespread adoption of Linux, this was less true; presumably the developers actually used non-Linux systems. -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 UUID library on RHEL does not have uuid_unparse_lower(). So you chose to use a function not reliably available. Sounds like bad planning to me. 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 flaw. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 _perfect_ application of ... autoconf! I spend quite a bit of my life working on non-Linux platforms (as well as a variety of Linux ones). I've built *lots* of free software on these platforms. 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 near impossible to fix. This is a cultural artifact (of a monoculture made possible by the relative dominance of linux in its niche), not a result of using autoconf. [In the early days of linux, it was much, _much_ worse, because not only didn't they use autoconf, they didn't even _try_ to be portable, simply assumed everything was exactly like the exact linux distribution they happened to be using.] Programs that work well with edit the makefile and define SYS to be sys-FOO.c style tend to program to the lowest common denominator, because doing anything else simply becomes too painful with this style of portability. This is fine for some apps (and indeed autoconf supports this sort of thing quite well), but in cases where you _need_ to use more esoteric functionality, it quickly becomes a real pain; autoconf's emphasis on finer-granularity helps considerably (though it's always going to be a pain). 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 made a hash of it no matter what style of portability they choose. -Miles -- o The existentialist, not having a pillow, goes everywhere with the book by Sullivan, _I am going to spit on your graves_. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
[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 near impossible to fix. This, as you note in your footnote, is probably attributable entirely to whether the developers actually have a clue that there is more to Unix than Linux/i386. The style of uncommenting defines in a Makefile, versus autoconf, is an _effect_, not a cause - the effect only _appears_ to be causal because the Unix-ignorant don't tend to use the former style. There is, either way, no substitute for awareness of portability issues, and no substitute for actual development experience on multiple Unix platforms. 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 macros are provided, but nobody forces you to use them. signature.asc Description: Digital signature
afraid to build from source? (was Re: Remove cdrtools)
[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 conditions. To me it is a very important philosophical point that Debian be self-hosting. That means packages should build without error from source, not just from intermediate text files like 'y.tab.c', 'configure', or 'Makefile.in' which, while arch-independent, are not particularly human-editable, and certainly not source code in the GPL sense. Using a provided 'configure' binary instead of building from source has the same problem as using any other provided binary rather than building from source. It clearly expresses a lack of confidence that the system _is_ in fact self-hosting. It tells our users, we will give you all the source code, but you'd better not modify that one configure.in source file, because we do not dare trust our tools to build it correctly. So yeah, I advocate always building packages from source, and if autoconf someday comes up with an incompatibility that causes a FTBFS somewhere, let that be reported and fixed. Not just worked around by trying to avoid running autoconf. signature.asc Description: Digital signature
Re: Remove cdrtools
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. [...] The situation is not helped when these mutually incompatible programs all prefer to be called automake or autoconf and, on less helpful distributions, do not install themselves as automake-1.9 (etc). Why should that matter at all? Autotools are tools for the upstream developer, and have had features to declare what version the configure.ac or Makefile.am files are supposed to be used with for quite some time now. You distribute a package that is already autotooled; the person who compiles the software doesn't need autotools. In case they do, your way of using autotools is horribly broken. This means the default operation of automake is horribly broken. No argument there. I once received a mail from someone who claimed he had argued for doing it this way, and that he regretted that he'd done so. Don't ask me who it was, however; I don't recall. (See the lengthy comment in /usr/share/doc/autotools-dev/README.Debian.gz on AM_MAINTAINER_MODE if its problems slipped your mind.) I would never forget about that issue ;-) The usual way for people to use version control is to keep the source, and provide scripts as appropriate to derive the program. Because of this, it is not common to put aclocal.m4, configure, or the other generated files into version control. Thus, anyone who downloads software from version control must run aclocal, autoheader, automake, autoconf, possibly libtool, etc. This is when backwards incompatible changes cause problems. If you work with VCS-snapshots, then I don't think it's still fair to consider yourself anything less than a developer. There will be some rough edges in that case -- not just because of the autotools usage. Proper use of AC_PREREQ and friends will ameliorate this problem, however. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
autotools (was Re: Remove cdrtools)
* 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 portability involves understanding your target systems, learning where the rough edges and corner cases are, and developing proper abstractions to work around them. I do not see how those two things interfere. You have to live with the differences, so you have to test them. And that autoconf does for you. What you do with this information is up to the program. You can either clutter everything with #ifdefs or write some abstraction that fits for your program and use all the information within there. Also the article you quoted says that system specific stuff should be as granular as possible, looking at the specific feature. And that is exactly what autoconf does. (Which both is one of its biggest advantages and also accounts for some of its disadvantages like the slowness). Bernhard R. Link -- Sendmail is like emacs: A nice operating system, but missing an editor and a MTA. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: autotools and programming style (was: Remove cdrtools)
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 system (or library version, or whatever), strewn throughout the entire codebase. Even when looking at somewhat related systems like *BSD and Linux, even opening an bluetooth RFComm socket _must_ use #ifdefs because this small OSS community cannot communicate about simple stuff like: - placing the bluetooth.h header file - naming values in the headerfile - names of the address structure and its elements. 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 the compilation, but nobody ever does. They just write a spaghettied mess in the main body of the code, like the examples. Real portability involves understanding your target systems, learning where the rough edges and corner cases are, and developing proper abstractions to work around them. Real life portability is often done for systems that you - did not install yourself - do not have steady access to or no access at all (only using documentation) or is done by people that somehow hacked into your peace of software to make it work in their systems (with absolutely no design goal in mind while porting). Absolutely. But that doesn't justify crap code. The whole autoconf system encourages minor patches and nasty #ifdefs rather than factoring out what's different from what's the same. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 what I was trying to express (badly) with or library versions or whatever.) Autoconf encourages writing mainline code with different branches in a maze of #ifdefs. Okay, maybe *autoconf* doesn't specificly encourage it, but thats how the vast majority of users of autoconf do it. 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. There are quite often subtlities in how things work on a particular system that are not distinguishable by simple compile tests about whether or not something is there. Real portability involves understanding your target systems, learning where the rough edges and corner cases are, and developing proper abstractions to work around them. Furthermore, 'best practice' use of autoconf is to isolate the feature differences in a single piece of wrapper code, so that your main code only has to deal with (e.g.) 'memmove', and it's emulated where it isn't present. The emulation code is the only code containing #ifdefs, which are then based on the features detected by autoconf. Ha ha ha ha. I admit there may be some out there who use it that way. Don't see it very often. Also, please, checking for memmove? This is 2006. Everytime I sit through the endless checking for memcpy()... crap I cringe. Why are we still wasting my time checking for features that were standardized 17 years ago? And don't give me the but it will still work on old/weird systems crap. Most of it won't even compile (much less work!) on Solaris 2.7 or AIX 5, and those are (relatively) recent C89/Posix environments. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: autotools and programming style (was: Remove cdrtools)
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 the compilation, but nobody ever does. They just write a spaghettied mess in the main body of the code, like the examples. On the bright side, with autoconf there's a plausible chance that people will be writing such spaghetti based on feature testing rather than writing such spaghetti based on platform detection defines exported by the system. Not brilliant but it's a bit of a win. it work in their systems (with absolutely no design goal in mind while porting). Absolutely. But that doesn't justify crap code. The whole autoconf system encourages minor patches and nasty #ifdefs rather than factoring out what's different from what's the same. I don't really think it's fair to blame autoconf for people writing tasteless code: the whole masses of ifdefs thing is a fairly standard danger sign that crops up even without autoconf providing the defines and it does have a fairly standard solution. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 system types, maybe. But nobody actually has that luxury in the real world. Coarse-grained system tests are a frigging nightmare in the real world. -Miles -- 97% of everything is grunge -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 very widespread. So is syphilis. That doesn't make it desirable. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
-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 speak for how nice it is, but autotools (for all its problems) is very widespread. So is syphilis. That doesn't make it desirable. But it *does* make it hard to eradicate... - -- Ron Johnson, Jr. Jefferson LA USA Is common sense really valid? For example, it is common sense to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that common sense is obviously wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE4N5DS9HxQb37XmcRAmbcAKDM4aX9qZu7wfnp8Rz/2VDgZWctEACgqhAF Md5XpR8Q4O69/17JqtGDfL4= =jdrl -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 speak for how nice it is, but autotools (for all its problems) is very widespread. So is syphilis. That doesn't make it desirable. Syphilis is a disease. Software usually isn't. In the case of autotools, the fact is that usually it's configure.ac or Makefile.am being horribly broken, rather than the autotools. If used properly, autotools usually do their job; and pretty well, too. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 used cmake myself, so I can't speak for how nice it is, but autotools (for all its problems) is very widespread. So is syphilis. That doesn't make it desirable. Syphilis is a disease. Software usually isn't. 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 primarily due to older versions of autotools encouraging or requiring behavior that later versions of autotools declare to be broken. automake is the persistent offender here -- conditionally compiled source files is a good example, where automake-1.5's info pages said to do it one way, 1.6 said to do it another way (and complained if you did it the 1.5 way), and IIRC 1.7+ prefer yet another way and broke the 1.5 way of doing things. autoconf has had some similar cases, such as the help string for AC_ARG_WITH -- which is used by a large majority of autotooled programs -- being one way for 2.59 but wanting AS_HELP_STRING in 2.59. Unfortunately, the old way produces goofy formatting (and maybe a warning; I forget exactly) under 2.59. The situation is not helped when these mutually incompatible programs all prefer to be called automake or autoconf and, on less helpful distributions, do not install themselves as automake-1.9 (etc). Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 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. So is syphilis. That doesn't make it desirable. Syphilis is a disease. Software usually isn't. For those who disparage automake: * apt-get source tcng * say a prayer; using multiple pantheons is a good idea * take a look at its Makefiles * have a drink or ten * for x in `find -iname Makefile`;do dd if=/dev/random ... For those who disparage autoconf, a look at Schily makesystem will have a similar effect. THESE are syphilis or worse. In the case of autotools, the fact is that usually it's configure.ac or Makefile.am being horribly broken, rather than the autotools. 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 autotools, but everything so far is A LOT worse. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 primarily due to older versions of autotools encouraging or requiring behavior that later versions of autotools declare to be broken. That's *one* of the problems. If you only ever compile on Linux or *BSD, it might seem the most common. 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 portability involves understanding your target systems, learning where the rough edges and corner cases are, and developing proper abstractions to work around them. Oh, and actually learning the standard version of the language (if there is one), and being able to distinguish between this is what the language says it will do and works for me. The sad thing is that Henry Spencer warned us 15 years ago[1], and nobody learned a damn thing. Steve [1] http://www.literateprogramming.com/ifdefs.pdf -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 cmake myself, so I can't speak for how nice it is, but autotools (for all its problems) is very widespread. So is syphilis. That doesn't make it desirable. Syphilis is a disease. Software usually isn't. In the case of autotools, the fact is that usually it's configure.ac or Makefile.am being horribly broken, rather than the autotools. If used properly, autotools usually do their job; and pretty well, too. Just have a look here http://lwn.net/Articles/188693 Cheers, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 portability involves understanding your target systems, learning where the rough edges and corner cases are, and developing proper abstractions to work around them. Oh, and actually learning the standard version of the language (if there is one), and being able to distinguish between this is what the language says it will do and works for me. I'm not sure you can really blame autotools for this. In a well-designed application with a good portability abstraction layer, the autotools are as good as any for providing the input required to create that portability layer. In other words, my preferred coding practice is to use autotools to probe the system capabilities and selectively enable a portability layer that deals with missing functionality required for that system. Then, isolate all #ifdefs and the like in that portability layer and code the rest of the application against standard POSIX and ISO C99 functionality, using the portability layer where necessary. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
autotools and programming style (was: Remove cdrtools)
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. 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. That's *one* of the problems. If you only ever compile on Linux or *BSD, it might seem the most common. See, nobody uses AC_PREREQ and still complains. 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. Even when looking at somewhat related systems like *BSD and Linux, even opening an bluetooth RFComm socket _must_ use #ifdefs because this small OSS community cannot communicate about simple stuff like: - placing the bluetooth.h header file - naming values in the headerfile - names of the address structure and its elements. The NetBSD guys soemwhat saw this and hacked in some bluez compatibility. But the normal way is different on Linux, FreeBSD and NetBSD (Solaris not competing here at all ;)). They all do the same but lack off communication and stubborness got us all into this situation. And loose standards cause this kind of things. Autotools is _not_ the cause for this and the ifdefs that it proposes are mostly short. Real portability involves understanding your target systems, learning where the rough edges and corner cases are, and developing proper abstractions to work around them. Real life portability is often done for systems that you - did not install yourself - do not have steady access to or no access at all (only using documentation) or is done by people that somehow hacked into your peace of software to make it work in their systems (with absolutely no design goal in mind while porting). Oh, and actually learning the standard version of the language (if there is one), and being able to distinguish between this is what the language says it will do and works for me. 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.) http://www.opengroup.org helps a lot. The sad thing is that Henry Spencer warned us 15 years ago[1], and nobody learned a damn thing. Interesting lecture. HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 because moc is designed to be used with qmake. HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 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. So is syphilis. That doesn't make it desirable. Syphilis is a disease. Software usually isn't. 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 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 programs all prefer to be called automake or autoconf and, on less helpful distributions, do not install themselves as automake-1.9 (etc). Why should that matter at all? Autotools are tools for the upstream developer, and have had features to declare what version the configure.ac or Makefile.am files are supposed to be used with for quite some time now. You distribute a package that is already autotooled; the person who compiles the software doesn't need autotools. In case they do, your way of using autotools is horribly broken. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 portability involves understanding your target systems, learning where the rough edges and corner cases are, and developing proper abstractions to work around them. Oh, and actually learning the standard version of the language (if there is one), and being able to distinguish between this is what the language says it will do and works for me. Use of gnulib can help with this. It provides a number of useful abstractions that can help to avoid #ifdefs in some common situations: http://savannah.gnu.org/p/gnulib -- Ben Pfaff email: [EMAIL PROTECTED] web: http://benpfaff.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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, or whatever), strewn throughout the entire codebase. Real portability involves understanding your target systems, learning where the rough edges and corner cases are, and developing proper abstractions to work around them. Oh, and actually learning the standard version of the language (if there is one), and being able to distinguish between this is what the language says it will do and works for me. I'm not sure you can really blame autotools for this. In a well-designed application with a good portability abstraction layer, the autotools are as good as any for providing the input required to create that portability layer. Indeed, the only reason to use autoconf in the first place is if you're trying to *avoid* platform-specific ifdef mazes. That some authors happen to do an imperfect job of this isn't something that should be blamed on autoconf AFAICS. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 programs all prefer to be called automake or autoconf and, on less helpful distributions, do not install themselves as automake-1.9 (etc). Why should that matter at all? Autotools are tools for the upstream developer, and have had features to declare what version the configure.ac or Makefile.am files are supposed to be used with for quite some time now. You distribute a package that is already autotooled; the person who compiles the software doesn't need autotools. In case they do, your way of using autotools is horribly broken. This means the default operation of automake is horribly broken. (See the lengthy comment in /usr/share/doc/autotools-dev/README.Debian.gz on AM_MAINTAINER_MODE if its problems slipped your mind.) The usual way for people to use version control is to keep the source, and provide scripts as appropriate to derive the program. Because of this, it is not common to put aclocal.m4, configure, or the other generated files into version control. Thus, anyone who downloads software from version control must run aclocal, autoheader, automake, autoconf, possibly libtool, etc. This is when backwards incompatible changes cause problems. On top of the default automake behavior being horribly broken, does that make usual revision control practices horribly broken? Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: autotools and programming style (was: Remove cdrtools)
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 to make a new standard based on the previous standard. Duh. Very common use case. The problem is not permission to change a standards document but permission to make a modified derivative of a standards document. I don't understand why people have such trouble understanding this. -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 write Makefiles, of course, which is a bigger problem. Automake doesn't know how to write them either. Google Make is an expert system. There should be as little as possible in the procedural code: if you can express something with dependencies, you should do it. Unfortunately Make is missing one crucial feature which would allow most Makefiles to be much, much cleaner. I have been meaning to write a patched version of make which includes it, but I never seem to get around to it. It's very simple: for each target, it should be possible to specify a piece of procedural code which returns 0 if the target is considered 'up-to-date' and 1 if it is not considered 'up-to-date'. Think about the potential uses of that for a minute. :-) 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. 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. Real portability involves understanding your target systems, learning where the rough edges and corner cases are, and developing proper abstractions to work around them. Furthermore, 'best practice' use of autoconf is to isolate the feature differences in a single piece of wrapper code, so that your main code only has to deal with (e.g.) 'memmove', and it's emulated where it isn't present. The emulation code is the only code containing #ifdefs, which are then based on the features detected by autoconf. I don't think I'd like to work without autoconf. The alternatives I've seen are all hideous monstrosities. Automake -- well, if you know how to write a Makefile, don't use it, just write your Makefile -- but most people don't. -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 autotools, but everything so far is A LOT worse. Yup. The autotools also have the rather nice attribute that if there's any pain involve, it's only on the part of the developer / distributor -- for the end user who just wants to compile and install the package, usually everything works quite smoothly, without the necessity of installing new obscure tools. The implementation pecularities of autoconf / automake can indeed be quite annoying at times, but the basic idea behind them is solid, and ends up working pretty well if you use them the right way. -Miles -- Is it true that nothing can be known? If so how do we know this? -Woody Allen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 there's this nice cmake? The cmake build system might even get accepted by Joerg, as it can create makefiles for MS compilers (I know, its not important to this list and also not to me, but it seems to be important for Joerg). Cheers, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 Joerg, as it can create makefiles for MS compilers (I know, its not important to this list and also not to me, but it seems to be important for Joerg). I'd consider that points /against/ it's favour. -- Jon Dowland http://alcopop.org/ signature.asc Description: Digital signature
Re: Remove cdrtools
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 widespread. the same for me. The cmake build system might even get accepted by Joerg, as it can create makefiles for MS compilers (I know, its not important to this list and also not to me, but it seems to be important for Joerg). I'd consider that points /against/ it's favour. If a new free fork is started JS has nothing to do with it, IMHO. -- :wq -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Remove cdrtools
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 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 automake thing). If you want to join that effort - contact me. For Debian etch I dont think its a big problem right now, dependencies will stop it from getting removed before we release. -- bye Joerg Some NM: 3. How do you manage new upstream releases? yes i manage them. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 :) ), 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 automake thing). If you want to join that effort - contact me. 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. One interesting thing on this project is that they want to turn important functionality into a shared library for improve the access from the various frontends. Regards, Francesco -- :wq -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
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 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 automake thing). If you want to join that effort - contact me. For Debian etch I dont think its a big problem right now, dependencies will stop it from getting removed before we release. For those that didn't see it on irc there is also a replacement for cdrecord called cdrskin based on the JS free libburn. The BIG problem with it is that it can only burn data CDs in disk-at-once mode. No TAO or audio capabilities. For anyone intrested Eduart Block and some others have packaged it in the last 24h: svn.debian.org/svn/collab-maint/deb-maint/cdrskin/trunk I know it is far from being a full replacement but good enough to e.g. burn Debian CDs. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
