Re: Man pages [Re: ignoring robots.txt]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Christopher G. Lewis wrote: Micah et al. - Just for an FYI - the whole texi-info, texi-html and (texi-rtf-hlp) is *very* fragile in the windows world. You actually have to download a *very* old version of makeinfo (1.68, not even on available on http://www.gnu.org/software/texinfo/) that supports RTF generation. Any progress that we take to work on this should look at a new texi-hlp (or chm) process or abandon the HLP format completely. The HLP format is kind of nice since you don't get one large HTML file, and has searching etc. But I believe there are issues w/ HLP files on either x64 or Vista (can't recall off the top of my head). So if it has to go away, so be it. Perhaps this is a good argument for using DocBook as the source format, as I believe openjade supports conversion to RTF. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGoFLf7M8hyUobTrERCKChAJ46RSLahpPKO9kgZxuLrcuEX1cHbQCdEqwU dmGMzOA2MzwNoWYxQJjqV/s= =RkiP -END PGP SIGNATURE-
Wget and Automake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I know this topic has been discussed before, but AFAICT it didn't really get far. Neither side presented particularly compelling arguments (IMHO), and so the burden of proof in arguing for change was not met. == Here are the reasons why I think moving to automake is the smart move: - Automatic tracking of GNU Coding Guidelines (which, in regard to Makefiles at least, tend to be pretty good ideas, but somewhat hard to implement/track without automake) - Automated packaging and package-testing - Automatic support for a wide variety of configuration and build scenarios, such as configuring or building from a location other than the source directory tree, or the DESTDIR late installation-location variable. - Included ability to modify the binary names (we can currently kludge this via $(exeext), but not to the degree that automake gives us this automatically). - Mauro, when he first brought it up some time ago, pointed to the fact that it has several grades of clean, which can be useful for various needs. - nothing but distribution list (also mostly automated), instead of everything but, which is superior IMO. This wouldn't be an argument for Automake by itself, since we could do this fairly easily ourselves... but little things add up. == Here are the arguments that I am currently aware of against using automake: - Complicated I actually don't find this to be true. The arguments to this effect seem to refer to the generated Makefiles but you don't _edit_ those. There is the argument that they are harder to debug, but personally I've never found this to be case; and I've had very little difficulty grokking the Makefiles themselves, actually. In terms of actually writing the Makefile.am documents, though, in general it is actually much _easier_ than writing the plain Makefile equivalents. - Support for non-recursive makes may not be great This is from my personal experience, though I later found some good solutions to the problems I had encountered. However, I believe this is likely to be far less well-supported than recursive builds. However, since Wget currently uses recursive builds, this really isn't an issue for us. - Another thing to know It's yet another tool for developers to have to learn. However, next to having to grok autoconf and Make and NLS, it's not difficult to learn, and IMO seems worth the nuisance, for the advantages that I've listed earlier. == I obviously wouldn't be looking to make the move for our upcoming 1.11 release in September; but I would desire to make the move soon thereafter. Since this was apparently something that some people felt strongly about, I thought it'd be wise to broach the subject now, so we have plenty of time to discuss it. So, please speak up! - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGoTZq7M8hyUobTrERCCm5AJ9Aj4JSEvXjx8QUTzjQAApI45sgCQCeOuQz iox1Q9qBfuSb7qWHuG6bjbM= =Wo6m -END PGP SIGNATURE-
Re: Wget and Automake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hrvoje Niksic wrote: Micah Cowan [EMAIL PROTECTED] writes: - Automated packaging and package-testing What packaging does this refer to exactly? Distribution tarballs. Automake has extremely good built-in creation and testing of distribution tarballs. It'll pack 'em up, then unpack it to someplace, do a build (IIRC, from a separate location from the unpacked source), and a test (I think?), and then check various properties on the results. It's very nice! - Automatic support for a wide variety of configuration and build scenarios, such as configuring or building from a location other than the source directory tree, or the DESTDIR late installation-location variable. This has worked with Autoconf-enabled programs (including Wget) for ages. Not very well, at least in the case of wget. For instance, *.gmo files end up in the source directories, rather than in separate build directories, at least at the moment. I'm sure this is easily fixed, but I suspect other issues may lurk. - Complicated I actually don't find this to be true. The arguments to this effect seem to refer to the generated Makefiles but you don't _edit_ those. I think this is the crucial point. If you really find the generated Makefiles to be managable, both in case when you need to edit them by hand (for whatever reason) and in the case when you need to understand them (to tell why something went wrong or to fix a problem), then Automake is the right choice. I find Automake-generated Makefiles to be completely unreadable and immutable. The only ones that even come close are the Makefiles generated by imake, and autotools were supposed to be a step forward. They could certainly be more readable, 'tis true. But so far I've always been able to find what I was looking for, and alter the Makefile.am file appropriately to fix the issue. I won't deny that Automake is not entirely flexible (and I should have mentioned this in the cons); but so far I have not run into a situation where I really could not make Automake do what I needed. I may have sometimes needed to write an ugly rule or two, but IMO the benefits far outweigh these problems. In terms of actually writing the Makefile.am documents, though, in general it is actually much _easier_ than writing the plain Makefile equivalents. As long as what you want to do is supported by Automake, yes. Heh, yeah, see above. :) I obviously wouldn't be looking to make the move for our upcoming 1.11 release in September; but I would desire to make the move soon thereafter. Since this was apparently something that some people felt strongly about, I thought it'd be wise to broach the subject now, so we have plenty of time to discuss it. So, please speak up! I don't think you will find hard technical arguments one way or the other; at this point the choice seems a matter of taste more than anything else. And as always in such matters, who does the work gets to make the call. Either way, I'll certainly support your decision. Thanks! :) I can't claim to be an Automake fanboy (or really, Autotools in general). I definitely believe it is not appropriate for all projects; but it's my (current) opinion that it is appropriate for this one. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGoUFL7M8hyUobTrERCKcCAJ97fv8UtKrPhdst6CWws70uqvE5DQCeJZoj pdn9EuXW8czWnaGvhBgPXe4= =4ofd -END PGP SIGNATURE-
