On Tue, 14 Apr 2015 21:50:01 +0200 Adrien Nader <adr...@notk.org> said:
> Hi, > > Let's get this straight: the title of this mail was only to trick you > into reading what's below and "considered harmful" should never be used. > > I'm updating win-builds.org with EFL git and ephysics failed building > because too many things use the EAPI define. > EAPI is useful because some platforms want that symbols exported from > shared libraries are explicitly marked and, conversely, when using > symbols from another shared library, they should be marked but > differently. > > Basically that means: > when eina_init() is compiled, it must be marked "dllexport" (for > Windows but this is also useful for ELF) and when it is used from my > application, its definition must be marked "dllimport". > > Simple enough. > > In the EFL world, this is achieved through EAPI. > Below is code from EPhysics.h: > > #ifdef EAPI > # undef EAPI > #endif > > #ifdef _WIN32 > # ifdef EFL_EPHYSICS_BUILD > # ifdef DLL_EXPORT > # define EAPI __declspec(dllexport) > # else > # define EAPI > # endif /* ! DLL_EXPORT */ > # else > # define EAPI __declspec(dllimport) > # endif /* ! EFL_EPHYSICS_BUILD */ > > > Then ephysics_world.cpp gets built with -DEFL_EPHYSICS_BUILD=1 and EAPI > gets "dllexport". That way, it will be possible to export the symbols > defined in ephysics_world.cpp. > Except that Eina.h is then included and since EFL_EINA_BUILD isn't > defined and the code in Eina.h is similar, we get #undef EAPI and then > #define again but for dllimport. Then the symbols are declared while > getting a decoration that means they are to be imported from another > shared library. That makes no sense and compilation aborts. > > There's the quick solution: include EPhysics.h after all others. > > There's the clean solution: stop abusing EAPI for 20 different > libraries. Think about it: today it's 20 but the goal is to get that > much higher; this will not happen if the order in which headers have to > be included is tricky. > Maybe that having EINA_API, EPHYSICS_API, ECORE_API, and so on looks a > bit tedious but at least it's simple to get right. > Another way to see it is that currently, a /single/ define (EAPI) is > controlled by 20 other defines (each of the EFL_.*_BUILD). > > To everyone writing new libraries: do not ever write "EAPI" in your code > but use a specific define for your library. i have to say.. a custom EAPI (EINA_API whatever) per library is just insane. the solution is far simpler. every header file must first #include <> deps (other libs) THEN #define it's own EAPI and continue delcaring its own (maybe #include it's own headers if it has multiple ala eina). this is far far far more managable. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
