Menu
▾
▴
fetchmail-devel
|
From: Matthias A. <ma...@dt...> - 2004-06-18 22:51:16
|
Dear fellow hackers, I've automake-ified fetchmail, but haven't commited the (huge!) change set yet. The reason I've done this before 6.2.6 is that I have been unable to compile the current intl/ stuff on Solaris and FreeBSD, and haven't been able to fix this. So I was fed up, upgraded gettext, switched to automake and voilà it works on SuSE Linux 8.2 x86 (with GCC 3.4 and ICC 8.0), on Solaris 8 SPARC (with GCC 3.4 and Sun Workshop) and on FreeBSD 4.10 i386. I believe I have tested this well, checked it is fully self-contained and am confident that after the commit, the package will still build. A bug the commit would also fix is the generation of text from HTML, which can currently create empty files if lynx isn't installed. Please let me know what you think. Rob, does this get your OK? If you can tell me how to fork a branch and commit that stuff to a branch, I'll do that, for the time being, I have exported the repository to a directory and packaged it as http://home.pages.de/~mandree/fetchmail/.hidden/fetchmail-6.2.6.svn+automake.tar.bz2 Building it after "autoreconf -is" with the software mentioned below works for me: This is what the new README.svn file reads: | In order to be able to build from the subversion repository (working | directory), some files need to be (re-)generated. | | Note that these generated files will be shipped with "make dist", | so the end user will not need these packages. | | The prerequisite packages are: | | - GNU autoconf >= 2.54 | - GNU automake >= 1.7 | - GNU gettext >= 0.13 | - GNU m4 | - bison or yacc | - flex or lex | | If you have these installed, type: | | $ rm -r -f autom4te.cache | $ autoreconf -i -s | | This will take a while and may print a lot of messages containing | "warning: unquoted definition of..." which are harmless. | | After that, build as usual, with | | $ ./configure --with-options | $ make | (become root) | # make install-strip | | -- Matthias Andree, 2004-06-18 This is what svn status prints: D ABOUT-NLS A Makefile.am D Makefile.in A README.svn D config.guess D config.sub M configure.in A dist-tools/Makefile.am A html2txt.sh D intl/ChangeLog D intl/Makefile.in D intl/VERSION D intl/bindtextdom.c D intl/cat-compat.c D intl/dcgettext.c D intl/dgettext.c D intl/explodename.c D intl/finddomain.c D intl/gettext.c D intl/gettext.h D intl/gettextP.h D intl/hash-string.h D intl/intl-compat.c D intl/l10nflist.c D intl/libgettext.h D intl/linux-msg.sed D intl/loadinfo.h D intl/loadmsgcat.c D intl/localealias.c D intl/po2tbl.sed.in D intl/textdomain.c D intl/xopen-msg.sed A m4 A m4/Makefile.am D mkinstalldirs D po/Makefile.in.in A po/Makevars M po/ca.po D po/cat-id-tbl.c M po/cs.po M po/da.po M po/de.po M po/el.po M po/es.po D po/fetchmail.pot M po/fr.po M po/gl.po M po/ja.po M po/pl.po M po/pt_BR.po M po/sk.po D po/stamp-cat-id M po/tr.po -- Matthias Andree Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 |
|
From: Rob F. <rf...@fu...> - 2004-06-18 23:33:51
|
Matthias Andree wrote: > I've automake-ified fetchmail, Sounds scary, but it's something that crossed my mind last night. > but haven't commited the (huge!) change > set yet. The reason I've done this before 6.2.6 is that I have been > unable to compile the current intl/ stuff on Solaris and FreeBSD, and > haven't been able to fix this. So I was fed up, upgraded gettext, > switched to automake and voilà it works on SuSE Linux 8.2 x86 (with GCC > 3.4 and ICC 8.0), on Solaris 8 SPARC (with GCC 3.4 and Sun Workshop) and > on FreeBSD 4.10 i386. Awesome! > A bug the commit would also fix is the generation of text from HTML, > which can currently create empty files if lynx isn't installed. I was actually wondering about moving that generation out of the makefile and into the makerelease script. Not sure though. That was mainly prompted by the conversion of the man page to HTML, which requires some infrastructure that we're not only not distributing, but isn't all that common. (Mainly the manServer.pl script I added to the dist-tools directory. Note that I don't intend for dist-tools to be included in the release, and I hope to move a bunch of Eric's release scripts into there.) I figured that if that conversion doesn't work with the distributed tarball, it's worth thinking about the same situation with the rest of the HTML generation. > Rob, does this get your OK? The general idea sounds good, especially the fact that you've tested on multiple platforms. The number of files touched is a bit scary, and I have minor reservations about some fringes of the process, but I think we can work those out later. > If you can tell me how to fork a branch and > commit that stuff to a branch, I'll do that, Heh, that's an area of svn I haven't explored yet. Check here for that info: http://svnbook.red-bean.com/ (I'm eagerly awaiting the print release of the book, which should get shipped to me when it comes out.) Unfortunately I'm going on an 8-day camping trip in a couple days and don't have time to look closely at this before I go. So I'll just suggest that you go ahead and commit it, but try to commit in coherent chunks if possible. That is, see if you can separate the automake stuff, the HTML generation, and the gettext stuff. I understand if that's not really possible though. Meanwhile, be sure to test actually running the result. (Argh, I still have to figure out how to deal with the torturetest server list, with its unpublishable passwords.) And I encourage everyone else to test building and running too. > Building it after "autoreconf -is" with the software mentioned below > works for me: > > This is what the new README.svn file reads: > | In order to be able to build from the subversion repository (working > | directory), some files need to be (re-)generated. It might be good to create a "bootstrap" script that removes that cache directory and does the autoreconf. And then change the makerelease script to call that instead of "aclocal && autoconf". > A dist-tools/Makefile.am I wouldn't think we'd need a makefile there. > D intl/ChangeLog > D intl/Makefile.in > D intl/VERSION > D intl/bindtextdom.c .... and so on Where's this intl functionality now? -- ==============================| "A microscope locked in on one point Rob Funk <rf...@fu...> |Never sees what kind of room that it's in" http://www.funknet.net/rfunk | -- Chris Mars, "Stuck in Rewind" |
|
From: Matthias A. <ma...@dt...> - 2004-06-18 23:48:31
|
Rob Funk <rf...@fu...> writes: >> A bug the commit would also fix is the generation of text from HTML, >> which can currently create empty files if lynx isn't installed. > > I was actually wondering about moving that generation out of the makefile > and into the makerelease script. Not sure though. That was mainly > prompted by the conversion of the man page to HTML, which requires some > infrastructure that we're not only not distributing, but isn't all that > common. (Mainly the manServer.pl script I added to the dist-tools > directory. Note that I don't intend for dist-tools to be included in the > release, and I hope to move a bunch of Eric's release scripts into there.) > I figured that if that conversion doesn't work with the distributed > tarball, it's worth thinking about the same situation with the rest of the > HTML generation. I had to add this to get "make distcheck" working. In the long run, it might be worthwhile converting the documentation to DocBook XML where appropriate, I believe ESR's doclifter can help with that, which will directly open PDF, man and HTML output formats. >> Rob, does this get your OK? > > The general idea sounds good, especially the fact that you've tested on > multiple platforms. The number of files touched is a bit scary, and I > have minor reservations about some fringes of the process, but I think we > can work those out later. Most of the stuff is auto-generated and will be copied into the build directory by autopoint, some will be copied by automake --add (this is all automatic by running autoreconf -i) > Unfortunately I'm going on an 8-day camping trip in a couple days and don't > have time to look closely at this before I go. So I'll just suggest that > you go ahead and commit it, but try to commit in coherent chunks if > possible. I fear the whole stuff is fairly atomic in the sense that I've only tested with the full change set applied, not in separate. configure.in and Makefile.am in particular track the po/ intl/... changes, and using automake/aclocal only enables us to use the m4/ subdirectory which takes the aclocal.m4 maintenance entirely off our shoulders. > That is, see if you can separate the automake stuff, the HTML > generation, and the gettext stuff. I understand if that's not really > possible though. automake and gettext is coupled, and HTML generation is a minor change, effectively, the separate lines have been consolidated in a shell script. > Meanwhile, be sure to test actually running the result. (Argh, I still > have to figure out how to deal with the torturetest server list, with its > unpublishable passwords.) Will do. > It might be good to create a "bootstrap" script that removes that cache > directory and does the autoreconf. And then change the makerelease script > to call that instead of "aclocal && autoconf". I don't like custom bootstrap scripts much. I have yet to see one that is better than "autoreconf" - and autom4te.cache will only need to be removed after a system upgrade, but not on a fresh checkout, so most people will get away without rm -rf. >> A dist-tools/Makefile.am > > I wouldn't think we'd need a makefile there. For the time being we'll need one if you want "make distcheck" to work, which I'd recommend as it greatly simplifies testing if the generated tarball is self-contained. We can still remove the stuff later if we have a good solution before the release. >> D intl/ChangeLog >> D intl/Makefile.in >> D intl/VERSION >> D intl/bindtextdom.c > .... and so on > > Where's this intl functionality now? autopoint will create the intl/ directory and populate it if you have gettext 0.13.0 or newer installed - this is the "generated files" category (copied files actually) - just try the tarball and you'll see. No jinx here, good magic. :) -- Matthias Andree Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 |
|
From: Matthias A. <ma...@dt...> - 2004-06-19 00:04:36
|
Rob Funk <rf...@fu...> writes: > Meanwhile, be sure to test actually running the result. (Argh, I still > have to figure out how to deal with the torturetest server list, with its > unpublishable passwords.) [X] Done [X] configured --with-ssl=... [X] worked with POP3 UIDL SSL KEEP [X] worked with IMAP SSL KEEP >> A dist-tools/Makefile.am > > I wouldn't think we'd need a makefile there. We can get away without if we ship the generated file. I'll commit RSN. -- Matthias Andree Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 |
|
From: Rob F. <rf...@fu...> - 2004-06-19 00:21:57
|
Matthias Andree wrote: > I had to add this to get "make distcheck" working. I get it. > In the long run, it > might be worthwhile converting the documentation to DocBook XML where > appropriate, I believe ESR's doclifter can help with that, which will > directly open PDF, man and HTML output formats. Yeah, good idea. > I fear the whole stuff is fairly atomic in the sense that I've only > tested with the full change set applied, not in separate. I'm OK with intermediate steps that aren't really tested. I like to be able to see the process. I'm not one who worries about each committed revision being usable. I'll say go ahead and commit it. You may want to put it on an AUTOMAKE branch, but I'll leave that up to you. If you put it on the trunk I'd suggest making a PRE_AUTOMAKE tag first. > > It might be good to create a "bootstrap" script that removes that > > cache directory and does the autoreconf. And then change the > > makerelease script to call that instead of "aclocal && autoconf". > > I don't like custom bootstrap scripts much. > I have yet to see one that is better than "autoreconf" - and > autom4te.cache will only need to be removed after a system upgrade, but > not on a fresh checkout, so most people will get away without rm -rf. Well, the bootstrap script I'm talking about would just codify what you're writing into the README.svn, particularly autoreconf and the options to use with it. That way it's visible without looking too hard, and is callable from things like makerelease. If we ever need to change the autoreconf options I only want to change it in one place. > >> A dist-tools/Makefile.am > > > > I wouldn't think we'd need a makefile there. > > For the time being we'll need one if you want "make distcheck" to work, OK, no big deal. > autopoint will create the intl/ directory and populate it if you have > gettext 0.13.0 or newer installed - this is the "generated files" > category (copied files actually) - just try the tarball and you'll see. > > No jinx here, good magic. :) Got it. Cool. -- ==============================| "A microscope locked in on one point Rob Funk <rf...@fu...> |Never sees what kind of room that it's in" http://www.funknet.net/rfunk | -- Chris Mars, "Stuck in Rewind" |
|
From: Matthias A. <ma...@dt...> - 2004-06-19 00:59:00
|
Rob Funk <rf...@fu...> writes: > I'm OK with intermediate steps that aren't really tested. I like to be able > to see the process. I'm not one who worries about each committed revision > being usable. The process is virtually inseparable. Splitting out singular changes doesn't make sense, it's really one large sweep. The po/ changes require automake, and intl/ is just a cleanup that has to come with the po/ update :-/ > I'll say go ahead and commit it. You may want to put it on an AUTOMAKE > branch, but I'll leave that up to you. If you put it on the trunk I'd > suggest making a PRE_AUTOMAKE tag first. I'll do. I'll also add a bootstrap.sh first because I found some peculiarities without. > Well, the bootstrap script I'm talking about would just codify what you're > writing into the README.svn, particularly autoreconf and the options to > use with it. That way it's visible without looking too hard, and is > callable from things like makerelease. If we ever need to change the > autoreconf options I only want to change it in one place. OK. -- Matthias Andree Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 |
|
From: Rob F. <rf...@fu...> - 2004-06-19 00:23:19
|
Matthias Andree wrote: > >> A dist-tools/Makefile.am > > > > I wouldn't think we'd need a makefile there. > > We can get away without if we ship the generated file. I don't expect to need to ship dist-tools/ at all. -- ==============================| "A microscope locked in on one point Rob Funk <rf...@fu...> |Never sees what kind of room that it's in" http://www.funknet.net/rfunk | -- Chris Mars, "Stuck in Rewind" |
|
From: Matthias A. <ma...@dt...> - 2004-06-19 00:36:29
|
Rob Funk <rf...@fu...> writes: > Matthias Andree wrote: >> >> A dist-tools/Makefile.am >> > >> > I wouldn't think we'd need a makefile there. >> >> We can get away without if we ship the generated file. > > I don't expect to need to ship dist-tools/ at all. We won't. :-) -- Matthias Andree Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X