On Sat, Jan 13, 2018 at 7:50 PM, Werner LEMBERG <[email protected]> wrote:
>
>> Btw, visual studio's project/sln files can contain compiler
>> preprocessor definitions also. You can do that FT_EXPORT redefine
>> hacks in those. There is no need to polute the rest of Freetype
>> source/header. The requirement is entirely visual studio specific
>> and mingw does not need it.
>
> But Visual C is a front-end to a command line compiler, isn't it?
it is.
> In
> that it makes sense to have this stuff in FreeType's header file also;
> for example, people want to call nmake manually...
also it is necessary for applications or libraries using freetype
that FT_EXPORT be defined to dllimport (which is currently the case).
I would like also to mention in the case of UNIX using gcc, that the
visibility of symbols can be changes by a compiler flags (remark that
there is a difference between gcc and windows compiler : on UNIX, gcc
exports all the symbols by default, which is the contrary on Windows).
so if, on UNIX, one passes -fvisibility=hidden to gcc, FT_EXPORT
should be defined as __attribute__ ((visibility("default")))
Here is what is done in a project which I contribute to (EAPI below is
the equivalent of FT_EXPORT) :
#ifdef _WIN32
# ifdef EFL_ECORE_WIN32_BUILD // useless in the case of freetype
# ifdef DLL_EXPORT
# define EAPI __declspec(dllexport)
# else
# define EAPI
# endif
# else
# define EAPI __declspec(dllimport)
# endif
#else
# ifdef __GNUC__
# if __GNUC__ >= 4
# define EAPI __attribute__ ((visibility("default")))
# else
# define EAPI
# endif
# else
# define EAPI
# endif
#endif
and we prepend EAPI in front of the declaration of public symbols
see https://gcc.gnu.org/wiki/Visibility for the documentation of
-fvisibility flag
Hth
Vincent Torri
_______________________________________________
Freetype-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype-devel
