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

[Martin P. <mb...@sa...>]

On 12 Jun 2003, Donovan Baarda <ab...@mi...> wrote:
> On Thu, 2003-06-12 at 11:51, Martin Pool wrote:
> > Rather than making the whole file autogenerated, I think it would
> > would be better to follow gtk and openssl in having a separate
> > librsync-config.h file which is generated from a .in file and included
> > by the main header.  It seems a little easier to keep the
> > autogenerated stuff separate from the parts that people will generally
> > want to look at or change.

> Does this librsync-config.h replace the existing config.h? And rsync.h
> (now librsync.h) includes librsync-config.h?

No, they're separate.  config.h is configured items necessary for
building the library, such as presence of particular system calls.  It
never leaves the build directory.  

librsync-config.h contains configured items that are necessary to
fully specify the public interface to the library, such as the
presence of types like "long long".

Ideally there would be none or very few of these, but I think knowing
the longest appropriate integer type probably is such a case.  We want
to have 64 bit types, "long" won't do, and we can't count on "long
long".  Perhaps we could assume stdint.h at the expense of derelict
platforms, but I think it's not too hard to do the librsync-config.h thing.

Keeping the configured header separate possibly also helps people on
platforms that can't run configure -- we can just ship a preconfigured
version for Win32.

> How does this impact on other projects that have their own config.h
> and include librsync.h?  Don't you get similar sorts of problems?

librsync-config.h needs to declare only appropriately qualified names,
such as 'typedef rs_long_long'.  

Neither librsync-config.h or librsync.h are allowed to either use or
declare autoconf-style names like HAVE_*.  They can of course be used
in implementation headers.

I've attached the GTK+-2.0 example.

I know it's a bit complex but I think it lets us present the cleanest
external interface.

-- 
Martin