libtool
[Top][All Lists]
Advanced

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

Re: [RFC] w32 and Libtool.


From: Simon Josefsson
Subject: Re: [RFC] w32 and Libtool.
Date: Thu, 14 Oct 2010 13:09:39 +0200
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux)

Peter Rosin <address@hidden> writes:

> DLL_EXPORT comes from libtool, so it should not be changed to
> LIBFOO_DLL_EXPORT.

Right.

> And while I approve of starting with LIBFOO_ instead of BUILDING_,
> LIBFOO_BUILDING sounds very wrong as BUILDING changes from a verb to a
> noun. LIBFOO_BUILD perhaps?  Other suggestions welcome.

The shorter the better, so LIBFOO_BUILD sounds better.

>> 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.

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.

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.

/Simon



reply via email to

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