[Imapfilter-devel] Patch to build imapfilter on Windows

[Danilo Almeida]

> To clarify my position a bit...
>
> The primary objective of imapfilter is to build and run under BSD
> and Linux. Support for other UNIX/UNIX-like (Hurd, Solaris, Irix,
> Cygwin, etc.) platforms will be added into the main distribution,
> because at most cases the changes that will need to be made will be
> insignificant.  But for platforms, such as in our case win32, where
> a lot of compatibility code needs to added, I think it is best to
> have the port separate from the main distribution.  I mean, it seems
> to be a little odd to burden the main distribution (which size is
> 25k) with 60k more code, just for it, to build under a specific
> platform.

I see your point.

How about keeping the non-Linux/BSD code out and just making sure to
create suitable abstractions to handle portability issues as they
arise?  The goal would be to make it easy to maintain a separate port
for other platforms (insofar as it is reasonable to do so, of course).

For example, for a Win32 port, Windows Sockets need to be initialized,
so have an init_sockets() function.  Similarly, we need closesocket(),
set_socket_nonblocking(), and unset_socket_nonblocking() (or
equivalents).  So we declare these functions in a separate portability
header (compat.h or similar) and provide definitions in a separate
module.  The mainline code would use these functions.  The defitions
for these functions would be something like:

int closesocket(int sock)
{
    return close(sock);
}

int init_sockets()
{
    return 0;
}

int set_socket_nonblocking(int sock)
{
    int flags = fcntl(sock, F_GETFL, 0);
    fcntl(sock, F_SETFL, flags | O_NONBLOCK);
    return flags;
}

void unset_socket_nonblocking(int sock, int flags)
{
    fcntl(sock, F_SETFL, flags);
}

Then, the Win32 port could simply replace the portability header and
module and provide any additional necessary supporting code (such as
getopt and regex).

Is that more reasonable?

> Anyway, something else that came to my mind is how portable will
> imapfilter be when for example Kerberos is added.  AFAIK, OpenSSL
> builds under win32 and with the addition of a regex, getopt and
> strsep implementation you can have the full functionality of
> imapfilter.  Is it possible to build and link Kerberos with
> imapfilter under win32?  And what about support for foo that will
> use libbar tomorrow?  Of course, there is always Cygwin...

With the proper abstractions, it should not be a problem.  In general,
I have found it pretty straightforward to do ports of programs that
use Kerberos.  The only difficulties arise when internal Kerberos
functions are used.  (Kerberos tens to be pretty bad about naming its
internal functions, so it is often hard to know what's private and
what's not.)

With the setup described above, the libbar case also gets handled by
just providing a port of libbar with the port version (or, as in the
case of OpenSSL, a pointer to the port).

- Danilo



_______________________________________________
Imapfilter-devel mailing list
Imapfilter-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/imapfilter-devel