efl/src/lib/evil/evil_main.h

127 lines
3.6 KiB
C
Raw Normal View History

#ifndef __EVIL_MAIN_H__
#define __EVIL_MAIN_H__
/**
* @page evil_main Evil
* @author Vincent Torri
* @date 2008 (created)
*
2020-02-28 02:01:56 -08:00
* @section evil_toc Table of Contents
*
* @li @ref evil_main_intro
* @li @ref evil_main_ack
* @li @ref evil_main_compiling
* @li @ref evil_main_next_steps
*
* @section evil_main_intro Introduction
*
* The Evil library is an evil library that ports some evil Unix
* functions to the Windows (XP or above, or Mobile) platform. The
* evilness is so huge that the most of the functions are not POSIX or
* BSD compliant.
*
* These functions are intended to be used inside the Enlightenment Foundation
* Libraries as private library and can be compiled only on Windows,
* using MSYS/MinGW on Windows, and cross-compilation on Unix. This
* library is minimal in the sense that only the functions needed to
* compile the EFL are available. The purpose of this library is NOT
* to have a full POSIX emulation et it is NOT a replacement of
* cygwin. To compare the size of the DLL themselves, Evil is around
* 33 KB and cygwin DLL is around 800 KB.
*
* @section evil_main_ack Acknowledgments
*
* This library has receive some from people interested in the EFL or
* not. Among them, evil thanks to Lars Munch, Raoul Hecky, Nicolas
* Aguirre, Tor Lillqvist, Lance Fetters, Vincent Richomme, Paul
* Vixie, Daniel Stenberg, who helped the author of the library in
* different fields (code and tests).
*
* @section evil_main_compiling How to compile
*
* Evil is a library your application links to. The procedure for
* this is very simple. You simply have to compile your application
* with the appropriate compiler flags that the @p pkg-config script
* outputs. For example:
*
* Compiling C or C++ files into object files:
*
* @verbatim
gcc -c -o main.o main.c `pkg-config --cflags evil`
@endverbatim
*
* Linking object files into a binary executable:
*
* @verbatim
gcc -o my_application main.o `pkg-config --libs evil`
@endverbatim
*
* See @ref pkgconfig
*
* @section evil_main_next_steps Next Steps
*
* After you understood what Evil is and installed it in your system
* you should proceed understanding the programming interface.
*
* Recommended reading:
*
* @li @ref Evil_Mman
* @li @ref Evil_Unistd_Group
* @li @ref Evil_Dlfcn
* @li @ref Evil_Locale_Group
* @li @ref Evil_Stdio_Group
* @li @ref Evil_Main_Group
* @li @ref Evil_String_Group
* @li @ref Evil_Stdlib_Group
* @li @ref Evil_Time_Group
*/
/**
* @file evil_main.h
* @brief The file that provides functions to initialize and shut down Evil.
* @defgroup Evil_Main_Group Main
* @ingroup Evil
*
* This header provides functions to initialize and shut down the Evil
* library.
*
* @{
*/
/**
* @brief Initialize the Evil library.
*
* This function initializes the Evil library. It must be called before
* using evil_time_get() or pipe(). It returns 0 on failure, otherwise it
* returns the number of times it has already been called.
*
* When Evil is not used anymore, call evil_shutdown() to shut down
* the Evil library.
*/
evil: Rename EAPI macro to EVIL_API in Evil library Summary: Patch from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass ```__attribute__ ((visibility ("default")))``` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). ``` Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as ```__atttribute__((visibility("default")))``` However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Reviewers: raster, vtorri, jptiz, lucas, woohyun Reviewed By: vtorri, jptiz Subscribers: ProhtMeyhet, cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D12182
2020-11-12 08:47:38 -08:00
EVIL_API int evil_init(void);
/**
* @brief Shut down the Evil library.
*
* @return 0 when the Evil library is completely shut down, 1 or
* greater otherwise.
*
* This function shuts down the Evil library. It returns 0 when it has
* been called the same number of times than evil_init().
*
* Once this function succeeds (that is, @c 0 is returned), you must
* not call any of the Evil function listed in evil_init()
* documentation anymore . You must call evil_init() again to use these
* functions again.
*/
evil: Rename EAPI macro to EVIL_API in Evil library Summary: Patch from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass ```__attribute__ ((visibility ("default")))``` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). ``` Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as ```__atttribute__((visibility("default")))``` However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Reviewers: raster, vtorri, jptiz, lucas, woohyun Reviewed By: vtorri, jptiz Subscribers: ProhtMeyhet, cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D12182
2020-11-12 08:47:38 -08:00
EVIL_API int evil_shutdown(void);
/**
* @}
*/
#endif /* __EVIL_MAIN_H__ */