[fetchmail-devel] Re: [fetchmail]fetchmail loaded into berlios svn repository; mailing lists

[Matthias A. <ma...@dt...>]

Rob Funk <rf...@fu...> writes:

> Matthias Andree wrote:
>> - in pop3_getpartialsizes, we may return uninitialized data iff first >
>> last (I don't know if this can happen, but I'd like to make the function
>> itself surprise free.)
>
> Good plan.

Committed (separate from the warning fixes).

>> - in po/POTFILES.in we're effectively listing rcfile_y.c a second
>>   time. It is in Makefile.in.in with proper path (top_builddir) and in
>>   POTFILES.in again, which makes gettext's makefile prepend top_srcdir -
>>   which fails, because rcfile_y.c is generated and hence in builddir.
>
> Odd.  I wonder how got that way and how (if) it ever worked properly.  

It works when builddir = srcdir.

> There's no RCS history on either of those files, but they were like that 
> in 6.2.5.

Makefile.in.in is a generated file.

> Will the rcfile_y strings be properly translated if you do this?

Dunno. I presume yes becasue Makefile.in.in still lists the file, but
I have just failed at soldering gettext 0.13 into the build, so I'll
quit that, I'm not going to waste time here. We can use automake first.

> Wait a minute.... every other file listed in POTFILES.in already exists.  
> So I'm not sure that this is the proper fix....

gettext.info suggests listing the source file rather than a generated
file, hence:

Index: po/POTFILES.in
===================================================================
--- po/POTFILES.in	(revision 3883)
+++ po/POTFILES.in	(working copy)
@@ -18,7 +18,7 @@
 opie.c
 options.c
 pop3.c
-rcfile_y.c
+rcfile_y.y
 report.c
 rfc822.c
 rpa.c

>>  To reproduce the problem:
>>  make distclean
>>  mkdir build
>>  cd build
>>  ../configure
>>  make
>
> I can't get past the ../configure -- it keeps telling me I need to make 
> distclean in the source directory, even though I did.

Some file must be lying in the way, but I don't know which ../configure
tests for.

> Argh.  autoconf is great for the user, but quite a pain for the
> developer.

The newer autoconf versions are better, but I wonder if you would want
the bild super structure replaced, I'd suggest deferring that to 6.2.7.

>> Is this OK to commit?
>
> I generally prefer that separate issues be committed separately, but other 
> than POTFILES.in, this stuff looks good to me.  I'm still trying to figure 
> out the autoconf and gettext stuff so I can even see the rcfiles_y 
> problem.

I've commited the ok = 0 initialization in one change, the warning fixes
in another and haven't yet committed the POTFILES.in patch, different
suggestion above. It adds an xgettext warning but fixes the build.

> BTW, the uni-dortmund address you sent this from isn't subscribed to 
> fetchmail-devel so I had to approve the message there.

Subscribed & set to nomail.

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95