Re: win32 Visual Studio 2005 project for gsasl

[Simon Josefsson]

Adam Strzelecki <address@hidden> writes:

>> (...) I now looked more closely how your patch in libidn
>> worked, and it used a perl script gen-win32-headers.pl.  That approach
>> seems good since avoids the static config.h which was part of your
>> gsasl
>> patch.  If you have the time, please use this approach for gsasl as
>> well.  I don't care strongly that gsasl.h is handled the same way,
>> having a GSASL_API define is fine, so maybe the gen-win32-headers.pl
>> script in gsasl could only for generating config.h.
>>
>> I'll wait with installing the other win32 related fixes until I hear
>> from you.
>
> Now Windows project related things:
>
> I reworked my project files so those are now using GSASL_API dll
> exports, and gen-win32-headers.pl to produce dynamically config.h in
> win32/include.

Great!

> * gsasl-lib-win32-dll-exports.patch + gsasl-lib-win32+vc8-3.patch
>
> Alternatively to those two here goes old version with .def file:
>
> * gsasl-lib-win32+vc8-2.patch
>
> I'm looking towards having those patches in the git repo.
>
> If you decide you use dll-exports please from now on mark all
> functions with GSASL_API rather than "extern".

I prefer the dll-exports idea -- the .def file approach is difficult to
maintain since it requires yet another file to modify when an API is
added.

However, I would like to preserve the 'extern' qualifier for functions
in the header file if possible.  I.e., something like:

/* GSASL Windows DLL */
#ifndef GSASL_API
# if defined(_WIN32) && !defined(GSASL_STATIC)
#  ifdef GSASL_EXPORTS
#   define GSASL_API  __declspec(dllexport)
#  else /* GSASL_EXPORTS */
#   define GSASL_API  __declspec(dllimport)
#  endif /* GSASL_EXPORTS */
#endif /* GSASL_API */
...
  extern GSASL_API int gsasl_init (Gsasl ** ctx);

Does the presence of the 'extern' keyword cause any problems for
compilation under Windows?

The gen-win32-headers.pl is GPLv3+, but libgsasl should be LGPLv2.1+.
Is it ok to use LGPLv2.1+ for it instead?  Also, I suggest adding a
statement like this after the license declaration:

# I consider the output of this program to be unrestricted.  Use it as
# you will.

With these changes, your patch could be installed.  I can roll a 0.2.28
immediately after your response.

Thanks,
/Simon