[redland-dev] Win32 - patch 1 of three

[Dave Beckett]

On Thu, 2005-05-19 at 22:51 +1200, John C Barstow wrote:
> On Thu, 2005-05-19 at 10:53 +0100, Dave Beckett wrote:
> > I only got two patches?
> > 
> Looks like the third one vanished somewhere. I'll resend a revised
> version after I incorporate your feedback; it's the changes to get the
> Python bindings built.

OK.

> > This is the merge summary:
> > 
> > rdf_model.c
> >   inline - no.  define REDLAND_INLINE and override in win32_rdf_config.h
> I've been looking at some other cross-platform code; many of them
> #define inline as __inline for Windows. Cygwin folks may want to speak
> up if this might cause them grief. Am I right in thinking that doing
> this would get rid of the XXX_INLINE macros?

REDLAND_INLINE can be #undef or #define to something else inside
win32_rdf_config.h.  I can't say whether __inline is right for win32 and
cygwin.  I assume there is a way to distinguish them.

> > redland.h
> >   change to "librdf.h" - no.  Fix this in your build system
> Yeah, this is an artifact of the learning process.
> 
> > raptor_general.c
> >   delete rdfxmla serializer - no.  Added #defines for serializers
> >   which can be disabled individually by your build environment or elsewhere.
> I'll look at this; if it still doesn't work I'll #define it away.
> 
> > raptor_uri.c
> >   one line edit - no.  need an explanation why this is done:
> > 	-  p=ud->path+1;
> > 	+  p=ud->path;
> This was to fix a bug I was experiencing. You'll note this is
> Win32-specific code and I kept losing the first character because of
> this.  I'm actually not sure why the +1 is there in the first place.

Can you give me the failing path so I can add it to the tests for win32
paths?

> I'm a little leery about maintaining this; can't file URIs be handed off
> to the same library that handles other protocols?

Because it may not always be available.  Although curl | libxml |
libfetch can retrieve uris they do not all provide a URI class with this
feature.

> > rasqal_internal.h
> >   inline - no. overridde in win32_rasqal_config.h if you need it
> OK.
> 
> I notice that both Windows and SPARQL #define OPTIONAL. I got around it
> through a quick hack; I don't know what the "correct" way to handle this
> is, but wonder if maybe the SPARQL constants should have a prefix/suffix
> to avoid collisions in the global namespace.

Windows defines OPTIONAL in a header?  Crazy.  The correct way would be
to #undef it in win32_rasqal_config.h as that's included before anything
else in all code (in rasqal).  I'd rather not add prefixes to the
constants since they appear in error messages and it's really handy that
errors in syntax report something slightly related to the actual token
names.

> One of the hardest problems to solve was the way the Microsoft compiler
> handles exported constants.  They need to be marked for export when
> building the library and explicitly marked for import when building a
> client that calls the library.

Right.  I recall something about this, maybe we need an extra macro for
constants separate from exporting functions.  Let me know what the win32
version should be.  A google suggests the versions are something like
this for windows:
   __declspec(dllimport) extern int foobar;
vs this for rest of the world:
   extern int foobar;

so I could create a #define REDLAND_PUBLIC ( RAPTOR_PUBLIC,
RASQAL_PUBLIC)
  REDLAND_PUBLIC int foobar;


> This is a problem because the version constants are used by the SWIG
> bindings, but SWIG can't handle this correctly (this has been reported
> as an issue countless times on the SWIG mailing lists).

Oh, I didn't know it wasn't working properly.

>   The short-term
> hack I'm using relies on modifying the generated C code.  Longer-term,
> I'm wondering if it's easier to point the bindings at simple wrapper
> functions that return the constant value rather than the constants
> themselves. Would that be reasonable?

Wrappers are possibilities, swig does make them for languages that can't
import such constants.

Dave