Den 2010-10-14 13:09 skrev Simon Josefsson:
> Peter Rosin <p...@lysator.liu.se> 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
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
