libmicrohttpd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libmicrohttpd] Re: ITALY - memory pool (2)


From: Diederick Huijbers | Apollo Media
Subject: Re: [libmicrohttpd] Re: ITALY - memory pool (2)
Date: Mon, 20 Sep 2010 01:33:04 +0200
User-agent: Thunderbird 2.0.0.24 (Windows/20100228)

Hi Carlos,

This weekend I created a static library with the help of some people on irc (#gnunet). You can find
some info on compiling libmicrohttpd on windows at this page:
http://github.com/roxlu/ofxHttpServer/raw/master/readme.txt

Kind regards,
Diederick

Carlos Henrique Júnior wrote:
I've been building a framework for C++ web development (still very academic, for now). It uses libmicrohttpd to provide a embedded server (also used as development server). A MSVC project file for libmicrohttpd would definitely help me to provide my framework to windows users, so I would most worry about my framework.

If you could do that, I would really appreciate, since I'm not an expert in MSVC as much as windows dev.

On Wed, Sep 15, 2010 at 9:02 PM, Christian Grothoff <address@hidden> wrote:
On Wednesday 15 September 2010 17:39:41 address@hidden wrote:
> Second step: I have to port the MHD library on a generic embedded platform.
> What I would do is:
>
>  - Replace all the POSIX calls in the code with function pointers
>
>  - Write an MHD_config (mhd_conf_t  *conf) function, where the caller
> passes the address of the actual function
>
> In this way the code can be compiled on any platform/compiler and we leave
> the end user to implement the actual functions.
> In principle, one can replace the TCP/IP stack with a RS232 stack as a
> transport layer.

I think this should be done using macros instead of function pointers.
Function pointers will confuse existing tools (such as static analysis tools)
and make the code harder to read for a feature that most users won't need.
We've used the macro approach to provide a POSIX-like API for W32 systems and
it worked quite well (PlibC).  Also, if you use macros, your C compiler will
likely be able to do a better job optimizing your code (especially for your
embedded system).


> That's the way I did it when I ported the FreeDOS FAT 16 filesystem.
>
>
> I see here also another smaller problem: the ordinary Windows user doesn't
> know how to build the code with Cygwin.
> I would add a separate project file for MSVC.
>
> What do you think?

I don't see a problem with having another build file --- however, I won't be
able to maintain it (no MSVC here...).  Still, even a slightly outdated build
file might be better than nothing for some users.

Happy hacking,

Christian




reply via email to

[Prev in Thread] Current Thread [Next in Thread]