rsync - Jan 2003 - Long-pending patch for Stratus VOS build

The following patch still applies cleanly to the current cvs copy of rsync.
I apply it each night after I grab rsync from the build farm. Without it, I
don't get far at all.  The purpose of the patch is to add executable
extension handling, which we need, and to clean up a few POSIX things and
supply defaults for a few #defines we don't have. (See the original letter
for full details).

Does anyone object to having these changes applied now, during the
pre-release phase?

http://lists.samba.org/pipermail/rsync/2002-November/008937.html

Thanks
PG
--
Paul Green, Senior Technical Consultant, Stratus Technologies.
Voice: +1 978-461-7557; FAX: +1 978-461-3610; Video on request.

On Fri, Jan 10, 2003 at 01:23:45PM -0500, Green, Paul
wrote:
> The following patch still applies cleanly to the current cvs copy of rsync.
Or did before the most recent Makefile.in changes.  It's easy to merge
this one problem, though.
> Does anyone object to having these changes applied now, during the
> pre-release phase?
Here are my comments on the changes:

 + The Makefile.in changes look very safe and needed.

 + The install-sh change to the dsttmp value looks good.

 ? I have a question about the portability of the u_FOO -> uFOO_t
   changes.  The former is the BSD syntax for the unsigned FOO typedefs,
   and the latter is what, POSIX?  The changes work on Linux, at least.
   Perhaps we should just make these changes and try it out on the
   compile farm.

 + The inet_pton changes look right to make the code consistent.  The
   only possible glitch might be a system that has a prototype for
   inet_pton() but not the library code -- if the prototype conflicts,
   the compile would fail (there are ways to work around this, but let's
   worry about that if we actually find some weird system with this
   problem).

I'd be glad to check in the "+" changes now if Dave thinks now is
a good
time.

..wayne..

Wayne Davison [mailto:wayned@users.sourceforge.net]
wrote:
>Here are my comments on the changes:
> ? I have a question about the portability of the u_FOO -> uFOO_t
>   changes.  The former is the BSD syntax for the unsigned FOO typedefs,
>   and the latter is what, POSIX?  The changes work on Linux, at least.
>   Perhaps we should just make these changes and try it out on the
>   compile farm.
Yes, uFOO_t is POSIX, 1990, IIRC.  



Thanks!
PG