bug-gnulib
[Top][All Lists]
Advanced

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

Re: automake conditional for visibility?


From: Simon Josefsson
Subject: Re: automake conditional for visibility?
Date: Wed, 04 Mar 2009 00:16:15 +0100
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)

Bruno Haible <address@hidden> writes:

> Hi Simon,
>
>> this part of the documentation for the "visibility" module
>> appears to assume that all public header files are generated from *.in
>> files via autoconf:
>
> Sure. That's the easiest way to ensure that an installed header file is
> self-contained.

But it doesn't hold for all projects.  I'm moving away from *.in
generated header files in my projects because my experience has been
that it generates more problems than it solves.  I think this is a
personal preference matter though.

>>    Define a macro specific to your library like this.
>>    @smallexample
>>    #if @@HAVE_VISIBILITY@@ && BUILDING_LIBFOO
>>    #define LIBFOO_DLL_EXPORTED __attribute__((__visibility__("default")))
>>    #else
>>    #define LIBFOO_DLL_EXPORTED
>>    #endif
>>    @end smallexample
>>    This macro should be enabled in all public header files of your library.
>> 
>> How about adding a automake conditional?  That would allow adding the
>> -DBUILDING_LIBFOO only when visibility is supported, like this:
>> 
>> if HAVE_VISIBILITY
>> AM_CPPFLAGS += -DBUILDING_LIBFOO
>> endif
>
> If you read further down, you will read that more complete support of native
> Windows platform requires an idiom like this:
>
> #if @HAVE_VISIBILITY@ && BUILDING_LIBFOO
> #define LIBFOO_DLL_EXPORTED __attribute__((__visibility__("default")))
> #elif defined _MSC_VER && BUILDING_LIBFOO
> #define LIBFOO_DLL_EXPORTED __declspec(dllexport)
> #elif defined _MSC_VER
> #define LIBFOO_DLL_EXPORTED __declspec(dllimport)
> #else
> #define LIBFOO_DLL_EXPORTED
> #endif
>
> Here, BUILDING_LIBFOO is also used when HAVE_VISIBILITY is not defined.
> So, your simplification works only in the simple case, but not in a more
> general setting.

Ah, right.

> But the essence of your remark is right: there is no need for the public
> header files to be generated from .in files. I'm applying the doc patch
> below.

Thanks, I'm going to test it now.

/Simon




reply via email to

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