Menu
▾
▴
fetchmail-devel
|
From: Graham W. <bo...@de...> - 2004-06-25 20:44:47
|
What is the purpose of the m4 directory? I can only see that is has one file in it (Makefile.am)? Also, would it be alright to move the macros from m4-local into one file (acinclude.m4)? I don't see any need to add a new directory for just one or a handful of new macros. -- gram |
|
From: Matthias A. <ma...@dt...> - 2004-06-26 02:11:30
|
Graham Wilson <bo...@de...> writes: > What is the purpose of the m4 directory? I can only see that is has one > file in it (Makefile.am)? Graham, the m4 directory is almost empty because the generated and copied files are not stored in the Subversion repository and the m4 directory, as the intl directory, is gettext's playground. The directory will be populated with c. 30 files by autopoint (which is part of GNU gettext and run from autogen.sh/autoreconf). The files are part of the distribution that "make dist" creates however, hence the Makefile.am in there. > Also, would it be alright to move the macros from m4-local into one file > (acinclude.m4)? I don't see any need to add a new directory for just one > or a handful of new macros. I have taken this acinclude.m4 approach in bogofilter and am not very happy with that, updating individual macros is then more effort than necessary. I'd rather stick with a file per macro (or file per logic group of macros, call it module if you like). Anyways you're right in that we needn't add a directory for the .m4 and .txt files, so I've moved the two files to the top level and dropped the m4-local directory and references to it. "make distcheck" still passes. (SVN Revision 3923.) Cheers, -- Matthias Andree Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 |
|
From: Graham W. <bo...@de...> - 2004-06-26 05:56:14
|
On Sat, Jun 26, 2004 at 02:11:24AM +0200, Matthias Andree wrote: > Graham Wilson <bo...@de...> writes: > > Also, would it be alright to move the macros from m4-local into one file > > (acinclude.m4)? I don't see any need to add a new directory for just one > > or a handful of new macros. > > I have taken this acinclude.m4 approach in bogofilter and am not very > happy with that, updating individual macros is then more effort than > necessary. I'd rather stick with a file per macro (or file per logic > group of macros, call it module if you like). Do you mean that you'd have to search through the global file, rather than replacing just a single file? If so, I'd rather go through that each time (I wouldn't think it would be too often) rather than have a bunch of M4 macro files laying around. Additionally, can't the license file be added to the top of the macro file, or to the COPYING file? Sorry for being persistent, I would just like to keep the tree as organized as possible. -- gram |
|
From: Matthias A. <ma...@dt...> - 2004-06-26 10:48:06
|
Graham Wilson <bo...@de...> writes: > On Sat, Jun 26, 2004 at 02:11:24AM +0200, Matthias Andree wrote: >> I have taken this acinclude.m4 approach in bogofilter and am not very >> happy with that, updating individual macros is then more effort than >> necessary. I'd rather stick with a file per macro (or file per logic >> group of macros, call it module if you like). > > Do you mean that you'd have to search through the global file, rather > than replacing just a single file? Yes, that's exactly it. > If so, I'd rather go through that each time (I wouldn't think it would > be too often) rather than have a bunch of M4 macro files laying > around. I've found that solution to be impractical and would rather have a set of files lingering on the floor that I can nuke individually. > Additionally, can't the license file be added to the top of the macro > file, or to the COPYING file? That might be doable but makes the COPYING file a bit lenghty and cumbersome to read. > Sorry for being persistent, I would just like to keep the tree as > organized as possible. That's why I went with m4-local first :) -- Matthias Andree Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 |
|
From: Graham W. <bo...@de...> - 2004-06-29 03:06:58
|
On Sat, Jun 26, 2004 at 10:48:02AM +0200, Matthias Andree wrote: > Graham Wilson <bo...@de...> writes: > > Sorry for being persistent, I would just like to keep the tree as > > organized as possible. > > That's why I went with m4-local first :) Well, if we are going to keep the M4 files seperate, we should use m4-local, otherwise, we should just keep it in one file. Rob, what do you think we should do? More generally, I think the automake stuff should have been committed to a branch, not to the trunk. Rob identified that the goals for the next version of fetchmail was just incoroporating the backlog of well-tested patches. I don't think the automake stuff qualifies, and I think we should have spent more time going over it. It is still possible to push the automake stuff to a branch, and revert the changes from the trunk. I think that is what we should do until after 6.2.6. For 6.2.6, I think we need to get the repository looking as close to esr's 6.2.5 tarball, plus the patches we have talked about. -- gram |
|
From: Matthias A. <ma...@dt...> - 2004-06-29 18:37:53
|
Graham Wilson <bo...@de...> writes: > Rob identified that the goals for the next version of fetchmail was just > incoroporating the backlog of well-tested patches. I don't think the > automake stuff qualifies, and I think we should have spent more time > going over it. It is still possible to push the automake stuff to a > branch, and revert the changes from the trunk. I think that is what we > should do until after 6.2.6. The automake patch wasn't intended to go into 6.2.6 but was agreed to by Rob because it allows us to fix build issues for instance on Solaris 8. I tried to fix just the build issues but something always broke :-/ My committing the patch was the practical approach. I'm willing to have it reverted the instant someone fixes the other build issues I was seeing and shows me that the conversion introduced a problem (regression). -- Matthias Andree Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 |
|
From: Rob F. <rf...@fu...> - 2004-06-30 21:38:04
|
Sorry it's taken me so long to get back into things here.... Graham Wilson wrote: > On Sat, Jun 26, 2004 at 10:48:02AM +0200, Matthias Andree wrote: > > Graham Wilson <bo...@de...> writes: > > > Sorry for being persistent, I would just like to keep the tree as > > > organized as possible. > > > > That's why I went with m4-local first :) > > Well, if we are going to keep the M4 files seperate, we should use > m4-local, otherwise, we should just keep it in one file. Rob, what do > you think we should do? I'm no autotools expert, so I'm not sure whether it's better to have separate m4 files or a single one. My intuition says separate though. I definitely agree with your assessment about whether to use the subdirectory. :-) > More generally, I think the automake stuff should have been committed to > a branch, not to the trunk. > > Rob identified that the goals for the next version of fetchmail was just > incoroporating the backlog of well-tested patches. I don't think the > automake stuff qualifies, and I think we should have spent more time > going over it. It is still possible to push the automake stuff to a > branch, and revert the changes from the trunk. I think that is what we > should do until after 6.2.6. I understand how you feel. The main reason I didn't push the branch was that Matthias was testing on three different OSs, and the non-automake version wouldn't build on at least one of them. (Though admittedly another factor was that I was on my way out for vacation.) > For 6.2.6, I think we need to get the repository looking as close to > esr's 6.2.5 tarball, plus the patches we have talked about. We need to do extensive changes to the release scripts anyway, which touches the build system, so I'm not too concerned about making changes to the build system. On the other hand, I want to minimize changes to the fetchmail code itself (i.e. C code) until after 6.2.6. -- ==============================| "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: Graham W. <bo...@de...> - 2004-06-29 19:22:34
|
On Tue, Jun 29, 2004 at 06:37:48PM +0200, Matthias Andree wrote: > My committing the patch was the practical approach. I'm willing to > have it reverted the instant someone fixes the other build issues I > was seeing and shows me that the conversion introduced a problem > (regression). I don't think the conversion necessarily introduces any problems. It didn't seem to long to me between when you announce the changes and committed them: I think we should've taken more time to go over the changes. However, if Rob is alright with having the automake changes in 6.2.6, I'll withdraw my criticisms. Did 6.2.5 work on Solaris? -- gram |
|
From: Matthias A. <ma...@dt...> - 2004-07-01 11:11:55
|
Graham Wilson <bo...@de...> writes: > However, if Rob is alright with having the automake changes in 6.2.6, > I'll withdraw my criticisms. > > Did 6.2.5 work on Solaris? It didn't compile with default options: | cd intl; make | make[1]: Entering directory `/var/tmp/fetchmail-6.2.5/intl' | make[1]: *** No rule to make target `libintl.@l@a', needed by `all-yes'. Stop. | make[1]: Leaving directory `/var/tmp/fetchmail-6.2.5/intl' | make: *** [@INTLDEPS@] Error 2 The workaround was --disable-nls. The current fetchmail version from SVN compiles fine and passes a simple smoke test (i. e. fetch local mail with IMAP, IMAP+SSL or POP3+SSL) on the same machine. -- Matthias Andree Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred) |
|
From: Graham W. <bo...@de...> - 2004-08-30 03:43:41
|
On Fri, Jun 25, 2004 at 01:44:21PM -0500, Graham Wilson wrote: > What is the purpose of the m4 directory? I can only see that is has one > file in it (Makefile.am)? > > Also, would it be alright to move the macros from m4-local into one file > (acinclude.m4)? I don't see any need to add a new directory for just one > or a handful of new macros. Revisiting this, it seems like we've decided to keep the autotool macros as individual files. Since we are going to do that, I think we all agree that they should be put in a subdirectory. Matthias, would it be alright to put the macros (and their license) into the m4 directory, or should the be put back into m4-local? -- gram |
|
From: Matthias A. <ma...@dt...> - 2004-09-01 00:03:55
|
Graham Wilson <bo...@de...> writes: > On Fri, Jun 25, 2004 at 01:44:21PM -0500, Graham Wilson wrote: >> What is the purpose of the m4 directory? I can only see that is has one >> file in it (Makefile.am)? >> >> Also, would it be alright to move the macros from m4-local into one file >> (acinclude.m4)? I don't see any need to add a new directory for just one >> or a handful of new macros. > > Revisiting this, it seems like we've decided to keep the autotool macros > as individual files. Since we are going to do that, I think we all agree > that they should be put in a subdirectory. Matthias, would it be alright > to put the macros (and their license) into the m4 directory, or should > the be put back into m4-local? Adding them to the m4 directory might be confusing, because the "autopoint" utility that will be run will update/copy files in(to) the m4/ directory (also po/, intl/). Finding out which files the license applies to will be a bit harder than usual, but there is no /technical/ reason to avoid putting the files into m4 AFAIK. As long as it's only one self-contained macro set, there is no reason not to name it acinclude.m4 either, but things are getting inconcise as the count of macros grows. -- Matthias Andree Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred) |
×
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