Re: [RFC] w32 and Libtool.

[Peter Rosin]

Den 2010-10-14 13:09 skrev Simon Josefsson:
> Peter Rosin <address@hidden> writes:
> 
>>> For comparison, in my projects I'm using a variant of this:
>>>
>>> # ifndef GSASL_API
>>> #  if defined GSASL_BUILDING && defined HAVE_VISIBILITY && HAVE_VISIBILITY
>>> #   define GSASL_API __attribute__((__visibility__("default")))
>>> #  elif defined GSASL_BUILDING && defined _MSC_VER && ! defined GSASL_STATIC
>>> #   define GSASL_API __declspec(dllexport)
>>> #  elif defined _MSC_VER && ! defined GSASL_STATIC
>>> #   define GSASL_API __declspec(dllimport)
>>> #  else
>>> #   define GSASL_API
>>> #  endif
>>> # endif
>>
>> I'm desperately trying to get away from having to specify (the
>> equivalence of) GSASL_STATIC when consuming libraries.
> 
> This was added to permit use of MSC to build static libraries, if I
> recall correctly.

It is with high probability not needed, see my 3rd version for how to
get rid of GSASL_STATIC.

> Another advantage with my variant is that it is possible to provide
> -DGSASL_API=foo during the build if you want to set some other attribute
> on the APIs.

That is a nice property that should perhaps be added to my variant in some
form. Good idea!

> The first issue (i.e., MSC static builds) could be handled by the means
> in the second point (i.e., project specifying -DGSASL_API="") though.
> Then there would be no need for GSASL_STATIC.
> 
> Anyway, I think the block will likely need to be adapted by each
> project.  I'm not trying to push for my version, just to offer it for
> comparison.

The only changes that should be needed is visibility attributes (which I
didn't want to discuss too much in the already complex text) and the
obvious s/LIBFOO_/LIBBAR_/ change. What other adaptations are needed?

BTW, I think it is somewhat ugly to mention HAVE_ defines in installed
headers, but since they are hidden behind GSASL_BUILDING it's acceptable.

Cheers,
Peter