XML-RPC for C/C++ (Xmlrpc-c)

As project maintainer, my first reaction is resistance, because I don't
know anything about Objective C and it seems like it could be a considerable
burden for me to package this and ensure quality.

On the other hand, it does seem to fit the package as well as C++ does, and
it's hard to say no to just disseminating files.

And I doubt there would be much demand for service.

What exactly is the form of your code and what sort of packaging do you have
in mind?

-- 
Bryan Henderson                                   San Jose, California

For anyone who doesn't know the language, Objective C seems like a cruel joke that got out of hand. Even the creators' names seem like a joke. (If you don't know the names, you should look them up.) It can include all native C libraries into it directly, which is what brought me, and others, to use xmlrpc-c with Objective C in the first place. 

The problem is that the Objective C programming model is distinctly adverse to code that blocks, which is similar to many GUI toolkits. This is the reason that I began to put together an alternative in the first place. My eventual goal would be to expand out the existing XMLRPC-C library to have an available asynchronous API using the LibCurl multi interface, which would be useful with the various GUI toolkits, Mac, Linux, and Windows alike.

Objective C is experiencing huge growth and I would like to have a working framework available and proximal to the XMLRPC-C code to allow other developers to use, and not have to spend the hundreds of hours debugging multi-threaded code for obscure bugs, as I had to.

What I have built is a single framework (XMLRPC.framework). I use a single main header file (xmlrpc.h) within it that includes all other necessary headers. I'm cleaning up the code a bit now and I'll send out a copy of it to the list later this week.

Neal Schilling 

On Feb 7, 2011, at 9:07 PM, Bryan Henderson <bryanh@...> wrote:

> As project maintainer, my first reaction is resistance, because I don't
> know anything about Objective C and it seems like it could be a considerable
> burden for me to package this and ensure quality.
> 
> On the other hand, it does seem to fit the package as well as C++ does, and
> it's hard to say no to just disseminating files.
> 
> And I doubt there would be much demand for service.
> 
> What exactly is the form of your code and what sort of packaging do you have
> in mind?
> 
> -- 
> Bryan Henderson                                   San Jose, California

>after *r2065* windows build was broken by adding new file to libutil. Also
>that file did not compile properly under windows.
>
>*string_number_vcproj.patch* - adds string_number.c and string_number.h to
>library build project
>
>*string_number_win32.patch* - fix export and compilation (int.h provides
>some C99's inttypes.h)

Thanks for debugging that.

I have applied the project file and XMLRPC_DLLEXPORT/__cplusplus changes, but
I need more information about whatever including "int.h" fixes.  Defining the
integer types is a difficult problem, but Xmlrpc-c has a solution for it.  I
don't remember the details of it right now, but I know lots of other files use
types such as are in <inttypes.h> and compile OK on Windows, so however those
work is what we should do here.  Definitions in win32_config.h have something
to do with it.

What exactly fails when the "int.h" is not there?

-- 
Bryan Henderson                                   San Jose, California

Bryan Henderson написав(ла):
[...]
> I have applied the project file and XMLRPC_DLLEXPORT/__cplusplus changes, but
> I need more information about whatever including "int.h" fixes.  Defining the
> integer types is a difficult problem, but Xmlrpc-c has a solution for it.  I
> don't remember the details of it right now, but I know lots of other files use
> types such as are in <inttypes.h> and compile OK on Windows, so however those
> work is what we should do here.  Definitions in win32_config.h have something
> to do with it.
> 
> What exactly fails when the "int.h" is not there?
> 

there are no stdbool.h in windows build, removing that header cause 
error about PRId64.

PRId64 is defined in:

lib/util/include/int.h

and also used by:

lib/libutil/base64.c
lib/libutil/utf8.c

so i decide to use "int.h" in a "string_number.c"

PS
for Visual Studio C99's headers like stdint.h and inttypes.h i use a 
http://code.google.com/p/msinttypes/

-- 
________________________________________
Maksym Veremeyenko

OK, thanks.  Your fix is exactly right, then.

I've included all the Windows build fixes in Release 1.25.03.

-- 
Bryan Henderson                                   San Jose, California

>First of all, Visual Studio can't find transport_config.h or xmlrpc_config.h
>anywhere.

I've never built on Windows, but I do know that Windows/xmlrpc_win32_config.h,
etc. are the files you need (copy/rename them).  For the older _static
library_ build, you use ConfigureWin32.bat to do that copy.  Maybe it or
something like it works for the DLL build too.

If you figure it out, you might write up a README for the next person.

-- 
Bryan Henderson                                   San Jose, California

Jake Wilson написав(ла):
> I'm having a hard time getting this thing to compile in Visual Studio 
> 2010 and I was wondering if anyone could help me out?
> 
> I've opened the solution in xmlrpc-c/Windows/dll.  When I try to build 
> any of the projects, like the cpptest project I get a lot of errors.
> 
> First of all, Visual Studio can't find transport_config.h or 
> xmlrpc_config.h anywhere.  And I don't see them anywhere in the source 
> folders either.  The include directories appear to be setup correctly. 
>  I assume that config.h files are generated when you ./configure the 
> source in Linux, but what do I do about it in Windows?
> 
> Any help would be appreciated.

before opening project run *ConfigureWin32.bat* in *Windows* dir...

please let me know, if something is wrong with Windows DLL compiling...


-- 
________________________________________
Maksym Veremeyenko