Re: [librsync-devel] Fix for rsync.h

[Donovan B. <ab...@mi...>]

On Thu, 2003-06-12 at 07:21, Wayne Davison wrote:
> Hi folks!  As I mentioned long, long ago, the rsync.h that gets
> installed has autoconf macros in it, which means that any program
> that uses librsync but either (1) does not use autoconf or (2) does
> not define SIZEOF_LONG_LONG will get an incompatible typedef for the
> rs_long_t type, and thus the call-back hooks can cause the program
> to crash.  I think that this is a serious enough problem that it
> should be fixed in the 0.9.6 release.  I've created a patch that
> should handle this.

Yeah, it does need fixing. One of the things I added to the TODO for
librsync is to create a common.h where all the autoconf macro's and have
everything else (except rsync.h I guess) include it.

The other thing is to make a proper libreplace.a library for autoconf
replacement functions.

There was some discussion a while back about problems with config.h when
linking with other things and I forget the conclusion... there might not
have been one. I remember being not comfortable with the
problems/solutions. There must be a better way to handle this, and
surely many other projects have had to deal with it.

> The patch changes configure.in to add a compile check for LONG_LONG
> and uses that if found, otherwise it uses either "long long" if its
> size wasn't 0, or just "long".  This duplicates the old #ifdefs in
> the rsync.h file.  The rsync.h file would be removed from CVS, and an
> rsync.h.in file committed that has a @RS_LONG_T@ variable reference
> that gets substituted by configure.  I also had to tweak autogen.sh.

There are also some complications related to this that affect building
librsync for a Python extension on win32. Python has it's own config.h
for MSVC that does some stuff. At one point I had the whole autoconf
setup working OK for everything, but much has changed since then and I
wouldn't be surprised if it was broken again (hence the desire but no
time to do all the win32 testing).

> The only thing I'm not sure is correct is what include files are
> needed for the LONG_LONG compile test on WIN32.  I currently have it
> just including sys/types.h, but I don't know if that is enough.

Yeah.. I'm a bit wary of introducing stuff that might break win32... I
haven't had a chance to test it properly for building on that platform. 
BTW, it seems "--build=windows32" has disappeared from the cygwin
autoconf... anyone know the current way to tell cygwin to build using
MSVC?

> In the process of changing configure.in, autoconf output an error
> that said we should be using AM_CONFIG_HEADER, not AC_CONFIG_HEADER,
> so I changed that as well.  Does anyone know if this is something
> new to autoconf 2.57 (which I'm using)?

Something to be careful of here... I thought that AM_CONFIG_HEADER was
deprecated in favour of AC_CONFIG_HEADERS. Check the autoconf info
pages. Also make sure that you are actually using autoconf version you
think... autoconf does some weird backwards compatibility tricks if it
thinks you are configuring using old autoconf files.

I just had a look at the automake 1.7 info page and it has the
following;

`AM_CONFIG_HEADER'
     Automake will generate rules to automatically regenerate the config
     header.  This obsolete macro is a synonym of `AC_CONFIG_HEADERS'
     today (Note: Optional).

Also, looking at the patch you have rsync.h as an output along with the
Makefiles etc. I'm not sure if it shouldn't be listed alongside config.h
in AC_CONFIG_HEADERS.

Otherwise, I use the rule "he who does it, gets to decide how it is
done". If you've fixed it and I haven't, then you have the right to
commit it :-)

-- 
Donovan Baarda <ab...@mi...>
http://minkirri.apana.org.au/~abo/