[redland-dev] Win32 - patch 1 of three

[John C Barstow]

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.

> 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.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.

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

> 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.

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.

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).  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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.gnomehack.com/pipermail/redland-dev/attachments/20050519/5700a68e/attachment.pgp