Re: [Nmh-workers] What about an nmh-1.6-RC1

[heymanj]

On 22 July 2014 at 12:31, Bill Wohler <address@hidden>wrote:

> David Levine <address@hidden> writes:
> 
>> Bill wrote:
>>
>>> But going forward Ken might be open to putting a link on the home
>>> page called "Snapshots" that points to some directory somewhere
>>> where the nightly build-bot can deposit a tarball called
>>> nmh-snapshot-<YYYYMMDD>>.tgz.
>>
>> I expect that wouldn't be worth the effort, both initial and
>> ongoing.
>>
>> And it should be very easy for a user to do this:
>>
>>     $ git clone git://git.savannah.nongnu.org/nmh.git
>>     $ cd nmh
>>     $ docs/contrib/build_nmh -di
>>
>> though on CentOS 6 and maybe others, that requires
>> installing a newer (at least 2.68) autoconf.  I don't know
>> what version of autoconf comes with CentOS 7.
> 
> Never mind, since what I was asking for was an amd64 binary snapshot,
> but that is probably untenable.

I own an amd64 system, so I thought I'd offer Bill a completed build.

I followed three steps above, and the result was:

address@hidden code]$ git clone git://git.savannah.nongnu.org/nmh.git
Cloning into 'nmh'...
remote: Counting objects: 18738, done.
remote: Compressing objects: 100% (4932/4932), done.
remote: Total 18738 (delta 13408), reused 18713 (delta 13393)
Receiving objects: 100% (18738/18738), 10.78 MiB | 124 KiB/s, done.
Resolving deltas: 100% (13408/13408), done.
address@hidden code]$ cd nmh
address@hidden nmh]$ docs/contrib/build_nmh -di
Install prefix [/usr/local]:      
Locking type (dot|fcntl|flock|lockf) [determined by configure]: 
MTS (smtp|sendmail/smtp|sendmail/pipe) [smtp]: 
SMTP server(s), space separated [localhost]: 
Cyrus SASL support [n]: n
TLS support [n]: 
make[2]: *** [install-auxexecPROGRAMS] Error 1
make[1]: *** [install-am] Error 2
make: *** [install] Error 2
sbr/dtimep.c:2368:17: warning: comparison between signed and unsigned integer 
expressions [-Wsign-compare]
build failed!
build log is in build_nmh.log

Further unwinding of the problem is that on my amd64 (Mageia 3) system,
size_t winds up being resolved as an 'unsigned long int' in the gcc 4.7.2
headers (/path/to/gcc/4.7.2/include/stddef.h).  The line in question is:

>         for ( i = 0; i < _yybytes_len; ++i )

where 'i' is an int, and _yybytes_len is size_t.  Since timep.c is generated 
by flex, so changing the _yy* variables isn't an easy out.  We could add

#define YY_TYPEDEF_YY_SIZE_T
typedef long int yy_size_t

to the dtimep.l source, but I'm concerned about the extern linkage in the
generated dtimep.c file immediately after (starting on line 156 of the file):

#ifndef YY_TYPEDEF_YY_SIZE_T
#define YY_TYPEDEF_YY_SIZE_T
typedef size_t yy_size_t;
#endif

extern yy_size_t yyleng;

Thoughts?

It is now 27yrs since I was introduced to MH and have been using it ever 
since.  First code I rehost on each OS as I have moved from AIX 2.2.1 ->
AIX 3.x, AIX 4.1 -> SCO Openserver 5 -> Unixware 7 -> Linux.  [there was
a failed attempt at QNX, but that's another story]

Love the code, wish to contribute more.

jerry
     // Jerry Heyman               | We are all born ignorant, but
    //  Amigan Forever :-)         | one must work hard to remain stupid
\\ //   heymanj at acm dot org     | -- Benjamin Franklin
 \X/    http://www.hobbeshollow.com|