Page MenuHomePhabricator

problem with EAPI on Windows (again)
Open, Incoming QueuePublic


on Windows, the purpose of EAPI is twice :

  1. When compiling a library, EAPI must be defined to __declspec(dllexport) so that symbols are exported
  2. When using this library, EAPI must be defined to __declspec(dllimport)

most of the EFL libraries (exception is elementary) define EAPI line that :

#ifdef _WIN32
# ifdef EFL_BUILD
#  ifdef DLL_EXPORT
#   define EAPI __declspec(dllexport)
#  else
#   define EAPI
#  endif
# else
#  define EAPI __declspec(dllimport)
# endif


  1. When compiling the EFL libraries, EFL_BUILD and DLL_EXPORT must be defined (not defining DLL_EXPORT means we want a static library, but we should avoid that on Windows)
  2. When using the libraries, EFL_BUILD must not be defined

The problem now is that autotools define EFL_BUILD for libraries and binaries. See m4/efl.m4, the EFL_LIB_END function, end of line 427 (as of today). This macro is used for each EFL parts in and each time EINA_CFLAGS, EET_CFLAGS, etc... are used (that is in Makefile_*.am). And these *_CFLAGS are used for libraries and binaries

When I first wrote the autotools, i defined EFL_BUILD directly in all the Makefile_*.am only for library

I know that autotools will be removed in favor of meson. This task is to be sure that meson will correctly define EFL_BUILD

vtorri created this task.Apr 10 2019, 9:34 PM
vtorri added a parent task: T7780: remove autotools.

@vtorri The problems with this in Elementary should be fixed. Do you see any others areas where this is wrong?

for each binary, EFL_BUILD must not be set. For each library, EFL_BUILD must be set. We must be sure that this is correctly done with meson. As I have said, it's a reminder for meson (see last line of my original message)

zmike added a comment.Sep 16 2019, 7:18 AM

Is this resolved?

zmike edited projects, added Restricted Project; removed efl: api.Sep 16 2019, 7:19 AM

This isn't an api issue...

no, EFL_BUILD is set in config.h, which is also used by binaries. see toplevel