2020-01-04 06:08:08 -08:00
|
|
|
#ifndef EINA_ABSTRACT_CONTENT_H
|
|
|
|
|
#define EINA_ABSTRACT_CONTENT_H
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* @typedef Eina_Content
|
2020-03-03 02:12:08 -08:00
|
|
|
* Container for any type of content.
|
2020-01-04 06:08:08 -08:00
|
|
|
*
|
2020-03-03 02:12:08 -08:00
|
|
|
* Each Eina_Content is made of an Eina_Slice of memory and an IANA MIME type:
|
|
|
|
|
* https://www.iana.org/assignments/media-types/media-types.xhtml
|
2020-01-04 06:08:08 -08:00
|
|
|
*
|
2020-03-03 02:12:08 -08:00
|
|
|
* @note If the type is any kind of text the last byte of the slice must be \0.
|
2020-01-04 06:08:08 -08:00
|
|
|
*
|
|
|
|
|
* @since 1.24
|
|
|
|
|
*/
|
|
|
|
|
typedef struct _Eina_Content Eina_Content;
|
|
|
|
|
|
|
|
|
|
/**
|
2020-03-03 02:12:08 -08:00
|
|
|
* @typedef Eina_Content_Conversion_Callback
|
2020-01-04 06:08:08 -08:00
|
|
|
*
|
2020-03-03 02:12:08 -08:00
|
|
|
* Method called when conversion from one type to another is requested.
|
|
|
|
|
* The from and to types are specified when the callback is registered.
|
2020-01-04 06:08:08 -08:00
|
|
|
* The to type is also passed in the callback here.
|
|
|
|
|
* The type of the from pointer does not need to be checked.
|
|
|
|
|
*/
|
|
|
|
|
typedef Eina_Content* (*Eina_Content_Conversion_Callback)(Eina_Content *from, const char *to_type);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Get the path to a file, containing the slice memory as content.
|
|
|
|
|
*
|
|
|
|
|
* @param[in] content The content that will be in the file.
|
|
|
|
|
*
|
|
|
|
|
* @return The path to the file. Do not free this.
|
|
|
|
|
*
|
|
|
|
|
*/
|
eina: Rename EAPI macro to EINA_API in Eina 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: jptiz, lucas, woohyun, vtorri, raster
Reviewed By: jptiz, lucas, vtorri
Subscribers: ProhtMeyhet, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12188
2020-11-25 04:35:48 -08:00
|
|
|
EINA_API const char* eina_content_as_file(Eina_Content *content);
|
2020-01-04 06:08:08 -08:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Convert the content of the object to another type.
|
|
|
|
|
*
|
2020-03-03 02:12:08 -08:00
|
|
|
* In case the conversion cannot be performed, NULL is returned.
|
2020-01-04 06:08:08 -08:00
|
|
|
*
|
|
|
|
|
* @param[in] content The content to convert.
|
|
|
|
|
* @param[in] new_type The new type the returned content will have.
|
|
|
|
|
*
|
|
|
|
|
* @return A new content object. The caller of this function is owning this.
|
|
|
|
|
*/
|
eina: Rename EAPI macro to EINA_API in Eina 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: jptiz, lucas, woohyun, vtorri, raster
Reviewed By: jptiz, lucas, vtorri
Subscribers: ProhtMeyhet, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12188
2020-11-25 04:35:48 -08:00
|
|
|
EINA_API Eina_Content* eina_content_convert(Eina_Content *content, const char *new_type);
|
2020-01-04 06:08:08 -08:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Get the type of the passed content.
|
|
|
|
|
*
|
|
|
|
|
* @param[in] content The content to fetch the type from.
|
|
|
|
|
*
|
|
|
|
|
* @return The type of this content. Do no free this.
|
|
|
|
|
*/
|
eina: Rename EAPI macro to EINA_API in Eina 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: jptiz, lucas, woohyun, vtorri, raster
Reviewed By: jptiz, lucas, vtorri
Subscribers: ProhtMeyhet, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12188
2020-11-25 04:35:48 -08:00
|
|
|
EINA_API const char* eina_content_type_get(Eina_Content *content);
|
2020-01-04 06:08:08 -08:00
|
|
|
|
|
|
|
|
/**
|
2020-03-03 02:12:08 -08:00
|
|
|
* Get the Eina_Slice of the passed content.
|
2020-01-04 06:08:08 -08:00
|
|
|
*
|
2020-03-03 02:12:08 -08:00
|
|
|
* @param[in] content The content to fetch the data from.
|
2020-01-04 06:08:08 -08:00
|
|
|
*
|
2020-03-03 02:12:08 -08:00
|
|
|
* @return An Eina_Slice containing the data. Do not free.
|
2020-01-04 06:08:08 -08:00
|
|
|
*/
|
eina: Rename EAPI macro to EINA_API in Eina 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: jptiz, lucas, woohyun, vtorri, raster
Reviewed By: jptiz, lucas, vtorri
Subscribers: ProhtMeyhet, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12188
2020-11-25 04:35:48 -08:00
|
|
|
EINA_API Eina_Slice eina_content_data_get(Eina_Content *content);
|
2020-01-04 06:08:08 -08:00
|
|
|
|
|
|
|
|
/**
|
2020-03-03 02:12:08 -08:00
|
|
|
* Create a new content object, with the provided data and type.
|
2020-01-04 06:08:08 -08:00
|
|
|
*
|
2020-03-03 02:12:08 -08:00
|
|
|
* @param[in] data A slice of memory. The memory is copied.
|
|
|
|
|
* @param[in] type The type this data represents.
|
2020-01-04 06:08:08 -08:00
|
|
|
*
|
|
|
|
|
* @return The new content object. The caller owns this object.
|
|
|
|
|
*/
|
eina: Rename EAPI macro to EINA_API in Eina 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: jptiz, lucas, woohyun, vtorri, raster
Reviewed By: jptiz, lucas, vtorri
Subscribers: ProhtMeyhet, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12188
2020-11-25 04:35:48 -08:00
|
|
|
EINA_API Eina_Content* eina_content_new(Eina_Slice data, const char *type);
|
2020-01-04 06:08:08 -08:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Free the content object.
|
|
|
|
|
*
|
|
|
|
|
* @param[in] content The content to free.
|
|
|
|
|
*/
|
eina: Rename EAPI macro to EINA_API in Eina 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: jptiz, lucas, woohyun, vtorri, raster
Reviewed By: jptiz, lucas, vtorri
Subscribers: ProhtMeyhet, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12188
2020-11-25 04:35:48 -08:00
|
|
|
EINA_API void eina_content_free(Eina_Content *content);
|
2020-01-04 06:08:08 -08:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Register a new conversion callback.
|
|
|
|
|
*
|
2020-03-03 02:12:08 -08:00
|
|
|
* @param[in] from The type to convert from.
|
|
|
|
|
* @param[in] to The type to convert to.
|
2020-01-04 06:08:08 -08:00
|
|
|
*
|
2020-03-03 02:12:08 -08:00
|
|
|
* @return True if the callback was successfully registered.
|
2020-01-04 06:08:08 -08:00
|
|
|
*/
|
eina: Rename EAPI macro to EINA_API in Eina 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: jptiz, lucas, woohyun, vtorri, raster
Reviewed By: jptiz, lucas, vtorri
Subscribers: ProhtMeyhet, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12188
2020-11-25 04:35:48 -08:00
|
|
|
EINA_API Eina_Bool eina_content_converter_conversion_register(const char *from, const char *to, Eina_Content_Conversion_Callback convertion);
|
2020-01-04 06:08:08 -08:00
|
|
|
|
|
|
|
|
/**
|
2020-03-03 02:12:08 -08:00
|
|
|
* Check if a specific conversion can be performed.
|
2020-01-04 06:08:08 -08:00
|
|
|
*
|
2020-03-03 02:12:08 -08:00
|
|
|
* A conversion can only be performed if a callback is registered.
|
2020-01-04 06:08:08 -08:00
|
|
|
*
|
2020-03-03 02:12:08 -08:00
|
|
|
* @param[in] from The type to convert from.
|
|
|
|
|
* @param[in] to The type to convert to.
|
2020-01-04 06:08:08 -08:00
|
|
|
*
|
2020-03-03 02:12:08 -08:00
|
|
|
* @return True if the conversion can be performed.
|
2020-01-04 06:08:08 -08:00
|
|
|
*/
|
eina: Rename EAPI macro to EINA_API in Eina 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: jptiz, lucas, woohyun, vtorri, raster
Reviewed By: jptiz, lucas, vtorri
Subscribers: ProhtMeyhet, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12188
2020-11-25 04:35:48 -08:00
|
|
|
EINA_API Eina_Bool eina_content_converter_convert_can(const char *from, const char *to);
|
2020-01-04 06:08:08 -08:00
|
|
|
|
|
|
|
|
/**
|
2020-03-03 02:12:08 -08:00
|
|
|
* Returns an iterator containing all the target types that the provided source type can be converted to.
|
2020-01-04 06:08:08 -08:00
|
|
|
*
|
2020-03-03 02:12:08 -08:00
|
|
|
* @param[in] from The type to convert from.
|
2020-01-04 06:08:08 -08:00
|
|
|
*
|
2020-03-03 02:12:08 -08:00
|
|
|
* @return An Iterator containing MIME type strings. Free this via eina_iterator_free.
|
2020-01-04 06:08:08 -08:00
|
|
|
*/
|
eina: Rename EAPI macro to EINA_API in Eina 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: jptiz, lucas, woohyun, vtorri, raster
Reviewed By: jptiz, lucas, vtorri
Subscribers: ProhtMeyhet, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12188
2020-11-25 04:35:48 -08:00
|
|
|
EINA_API Eina_Iterator* eina_content_converter_possible_conversions(const char *from);
|
2020-01-04 06:08:08 -08:00
|
|
|
|
eina: Rename EAPI macro to EINA_API in Eina 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: jptiz, lucas, woohyun, vtorri, raster
Reviewed By: jptiz, lucas, vtorri
Subscribers: ProhtMeyhet, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12188
2020-11-25 04:35:48 -08:00
|
|
|
EINA_API extern const Eina_Value_Type *EINA_VALUE_TYPE_CONTENT;
|
2020-01-04 06:08:08 -08:00
|
|
|
|
|
|
|
|
/**
|
2020-03-03 02:12:08 -08:00
|
|
|
* Convert the Eina_Content object to an Eina_Value.
|
2020-01-04 06:08:08 -08:00
|
|
|
*
|
2020-03-03 02:12:08 -08:00
|
|
|
* @param[in] content The Eina_Content struct that will be converted to an Eina_Value.
|
2020-01-04 06:08:08 -08:00
|
|
|
*
|
2020-03-03 02:12:08 -08:00
|
|
|
* @return An newly-allocated Eina_Value. Caller owns it.
|
2020-01-04 06:08:08 -08:00
|
|
|
*/
|
eina: Rename EAPI macro to EINA_API in Eina 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: jptiz, lucas, woohyun, vtorri, raster
Reviewed By: jptiz, lucas, vtorri
Subscribers: ProhtMeyhet, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12188
2020-11-25 04:35:48 -08:00
|
|
|
EINA_API Eina_Value* eina_value_content_new(Eina_Content *content);
|
2020-01-04 06:08:08 -08:00
|
|
|
|
|
|
|
|
/**
|
2020-03-03 02:12:08 -08:00
|
|
|
* Creates an Eina_Value from an Eina_Content.
|
2020-01-04 06:08:08 -08:00
|
|
|
*
|
2020-03-03 02:12:08 -08:00
|
|
|
* @param[in] content The Eina_Content struct that will be converted to an Eina_Value.
|
2020-01-04 06:08:08 -08:00
|
|
|
*
|
2020-03-03 02:12:08 -08:00
|
|
|
* @return An Eina_Value with type EINA_VALUE_TYPE_CONTENT.
|
2020-01-04 06:08:08 -08:00
|
|
|
*/
|
eina: Rename EAPI macro to EINA_API in Eina 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: jptiz, lucas, woohyun, vtorri, raster
Reviewed By: jptiz, lucas, vtorri
Subscribers: ProhtMeyhet, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12188
2020-11-25 04:35:48 -08:00
|
|
|
EINA_API Eina_Value eina_value_content_init(Eina_Content *content);
|
2020-01-04 06:08:08 -08:00
|
|
|
|
|
|
|
|
/**
|
2020-03-03 02:12:08 -08:00
|
|
|
* Gets the content from the Eina_Value.
|
2020-01-04 06:08:08 -08:00
|
|
|
*
|
2020-03-03 02:12:08 -08:00
|
|
|
* If the value is not of the type EINA_VALUE_TYPE_CONTENT, NULL will be returned and an error will be printed.
|
2020-01-04 06:08:08 -08:00
|
|
|
*
|
|
|
|
|
* @param[in] value The value to get the content from
|
|
|
|
|
*
|
2020-03-03 02:12:08 -08:00
|
|
|
* @return A newly-allocated Eina_Content. Caller owns it.
|
2020-01-04 06:08:08 -08:00
|
|
|
*/
|
eina: Rename EAPI macro to EINA_API in Eina 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: jptiz, lucas, woohyun, vtorri, raster
Reviewed By: jptiz, lucas, vtorri
Subscribers: ProhtMeyhet, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12188
2020-11-25 04:35:48 -08:00
|
|
|
EINA_API Eina_Content* eina_value_to_content(const Eina_Value *value);
|
2020-01-04 06:08:08 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
static inline Eina_Iterator*
|
|
|
|
|
eina_content_possible_conversions(Eina_Content *content)
|
|
|
|
|
{
|
|
|
|
|
return eina_content_converter_possible_conversions(eina_content_type_get(content));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#endif
|
