2012-12-02 14:35:45 -08:00
|
|
|
|
|
|
|
### Library
|
|
|
|
|
2014-10-02 08:52:45 -07:00
|
|
|
ecore_con_eolian_files = \
|
efl.net: socket, server and dialer for TCP.
Efl.Net.Server defines how to accept new connections, doing the
bind(), listen() and accept() for protocols such as TCP.
Efl.Net.Dialer defines to to reach a server.
Both are based on Efl.Net.Socket as communication interface that is
based on Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being
usable with code such as Efl.Io.Copier.
The Server will emit an event "client,add" with the established
Socket, which is a child and can be closed by both the server or the
user.
The Dialer extends the Socket and allows for creating one given an
address, that will be resolved and connected.
TCP is the initial implementation so we an validate the
interfaces. UDP, Unix-Local and SSL will come later as derivate
classes.
The examples are documented and should cover the basic principles:
- efl_io_copier_example can accept "tcp://IP:PORT" and will work as a
"netcat", can send data from socket, file or stdin to a socket,
file, stdout or stderr.
- efl_net_server_example listens for connections and can either reply
"Hello World!" and take some data or work as an echo-server,
looping back all received data to the user.
More complex interactions that require a "chat" between client and
server will be covered with new classes later, such as a queue that
empties itself once data is read.
2016-08-17 21:53:16 -07:00
|
|
|
lib/ecore_con/efl_net_socket.eo \
|
efl_net_{socket,dialer,server}_simple: easy to use, buffered network sockets.
The low level I/O primitives are powerful but adds some complexity to
use, for bi-directional streaming communication one ends creating two
Efl.Io.Queue and two Efl.Io.Copier to pipe data to socket when it can
operate.
Then encapsulate the socket using the new Efl.Io.Buffered_Stream, this
will allow the socket, be a dialer or a server client, to be operated
as a single handle that internally carries about the buffering for
you.
As one can see in the examples, compared to their "manual"
alternatives they are very easy to use, ressembling
Ecore_Con_Server/Ecore_Con_Client, but also offers line-based
delimiters and the possibility to let the socket to handle queueing
for you in case you received partial messages (just do not
read/clear/discard the received data).
2016-11-25 11:18:34 -08:00
|
|
|
lib/ecore_con/efl_net_socket_simple.eo \
|
efl.net: socket, server and dialer for TCP.
Efl.Net.Server defines how to accept new connections, doing the
bind(), listen() and accept() for protocols such as TCP.
Efl.Net.Dialer defines to to reach a server.
Both are based on Efl.Net.Socket as communication interface that is
based on Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being
usable with code such as Efl.Io.Copier.
The Server will emit an event "client,add" with the established
Socket, which is a child and can be closed by both the server or the
user.
The Dialer extends the Socket and allows for creating one given an
address, that will be resolved and connected.
TCP is the initial implementation so we an validate the
interfaces. UDP, Unix-Local and SSL will come later as derivate
classes.
The examples are documented and should cover the basic principles:
- efl_io_copier_example can accept "tcp://IP:PORT" and will work as a
"netcat", can send data from socket, file or stdin to a socket,
file, stdout or stderr.
- efl_net_server_example listens for connections and can either reply
"Hello World!" and take some data or work as an echo-server,
looping back all received data to the user.
More complex interactions that require a "chat" between client and
server will be covered with new classes later, such as a queue that
empties itself once data is read.
2016-08-17 21:53:16 -07:00
|
|
|
lib/ecore_con/efl_net_socket_fd.eo \
|
|
|
|
lib/ecore_con/efl_net_socket_tcp.eo \
|
2016-10-18 13:51:59 -07:00
|
|
|
lib/ecore_con/efl_net_socket_udp.eo \
|
efl.net: socket, server and dialer for TCP.
Efl.Net.Server defines how to accept new connections, doing the
bind(), listen() and accept() for protocols such as TCP.
Efl.Net.Dialer defines to to reach a server.
Both are based on Efl.Net.Socket as communication interface that is
based on Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being
usable with code such as Efl.Io.Copier.
The Server will emit an event "client,add" with the established
Socket, which is a child and can be closed by both the server or the
user.
The Dialer extends the Socket and allows for creating one given an
address, that will be resolved and connected.
TCP is the initial implementation so we an validate the
interfaces. UDP, Unix-Local and SSL will come later as derivate
classes.
The examples are documented and should cover the basic principles:
- efl_io_copier_example can accept "tcp://IP:PORT" and will work as a
"netcat", can send data from socket, file or stdin to a socket,
file, stdout or stderr.
- efl_net_server_example listens for connections and can either reply
"Hello World!" and take some data or work as an echo-server,
looping back all received data to the user.
More complex interactions that require a "chat" between client and
server will be covered with new classes later, such as a queue that
empties itself once data is read.
2016-08-17 21:53:16 -07:00
|
|
|
lib/ecore_con/efl_net_dialer.eo \
|
efl_net_{socket,dialer,server}_simple: easy to use, buffered network sockets.
The low level I/O primitives are powerful but adds some complexity to
use, for bi-directional streaming communication one ends creating two
Efl.Io.Queue and two Efl.Io.Copier to pipe data to socket when it can
operate.
Then encapsulate the socket using the new Efl.Io.Buffered_Stream, this
will allow the socket, be a dialer or a server client, to be operated
as a single handle that internally carries about the buffering for
you.
As one can see in the examples, compared to their "manual"
alternatives they are very easy to use, ressembling
Ecore_Con_Server/Ecore_Con_Client, but also offers line-based
delimiters and the possibility to let the socket to handle queueing
for you in case you received partial messages (just do not
read/clear/discard the received data).
2016-11-25 11:18:34 -08:00
|
|
|
lib/ecore_con/efl_net_dialer_simple.eo \
|
efl.net: socket, server and dialer for TCP.
Efl.Net.Server defines how to accept new connections, doing the
bind(), listen() and accept() for protocols such as TCP.
Efl.Net.Dialer defines to to reach a server.
Both are based on Efl.Net.Socket as communication interface that is
based on Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being
usable with code such as Efl.Io.Copier.
The Server will emit an event "client,add" with the established
Socket, which is a child and can be closed by both the server or the
user.
The Dialer extends the Socket and allows for creating one given an
address, that will be resolved and connected.
TCP is the initial implementation so we an validate the
interfaces. UDP, Unix-Local and SSL will come later as derivate
classes.
The examples are documented and should cover the basic principles:
- efl_io_copier_example can accept "tcp://IP:PORT" and will work as a
"netcat", can send data from socket, file or stdin to a socket,
file, stdout or stderr.
- efl_net_server_example listens for connections and can either reply
"Hello World!" and take some data or work as an echo-server,
looping back all received data to the user.
More complex interactions that require a "chat" between client and
server will be covered with new classes later, such as a queue that
empties itself once data is read.
2016-08-17 21:53:16 -07:00
|
|
|
lib/ecore_con/efl_net_dialer_tcp.eo \
|
2016-10-18 13:51:59 -07:00
|
|
|
lib/ecore_con/efl_net_dialer_udp.eo \
|
2016-08-19 20:55:26 -07:00
|
|
|
lib/ecore_con/efl_net_dialer_http.eo \
|
2016-08-29 20:28:00 -07:00
|
|
|
lib/ecore_con/efl_net_dialer_websocket.eo \
|
efl.net: socket, server and dialer for TCP.
Efl.Net.Server defines how to accept new connections, doing the
bind(), listen() and accept() for protocols such as TCP.
Efl.Net.Dialer defines to to reach a server.
Both are based on Efl.Net.Socket as communication interface that is
based on Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being
usable with code such as Efl.Io.Copier.
The Server will emit an event "client,add" with the established
Socket, which is a child and can be closed by both the server or the
user.
The Dialer extends the Socket and allows for creating one given an
address, that will be resolved and connected.
TCP is the initial implementation so we an validate the
interfaces. UDP, Unix-Local and SSL will come later as derivate
classes.
The examples are documented and should cover the basic principles:
- efl_io_copier_example can accept "tcp://IP:PORT" and will work as a
"netcat", can send data from socket, file or stdin to a socket,
file, stdout or stderr.
- efl_net_server_example listens for connections and can either reply
"Hello World!" and take some data or work as an echo-server,
looping back all received data to the user.
More complex interactions that require a "chat" between client and
server will be covered with new classes later, such as a queue that
empties itself once data is read.
2016-08-17 21:53:16 -07:00
|
|
|
lib/ecore_con/efl_net_server.eo \
|
efl_net_{socket,dialer,server}_simple: easy to use, buffered network sockets.
The low level I/O primitives are powerful but adds some complexity to
use, for bi-directional streaming communication one ends creating two
Efl.Io.Queue and two Efl.Io.Copier to pipe data to socket when it can
operate.
Then encapsulate the socket using the new Efl.Io.Buffered_Stream, this
will allow the socket, be a dialer or a server client, to be operated
as a single handle that internally carries about the buffering for
you.
As one can see in the examples, compared to their "manual"
alternatives they are very easy to use, ressembling
Ecore_Con_Server/Ecore_Con_Client, but also offers line-based
delimiters and the possibility to let the socket to handle queueing
for you in case you received partial messages (just do not
read/clear/discard the received data).
2016-11-25 11:18:34 -08:00
|
|
|
lib/ecore_con/efl_net_server_simple.eo \
|
efl.net: socket, server and dialer for TCP.
Efl.Net.Server defines how to accept new connections, doing the
bind(), listen() and accept() for protocols such as TCP.
Efl.Net.Dialer defines to to reach a server.
Both are based on Efl.Net.Socket as communication interface that is
based on Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being
usable with code such as Efl.Io.Copier.
The Server will emit an event "client,add" with the established
Socket, which is a child and can be closed by both the server or the
user.
The Dialer extends the Socket and allows for creating one given an
address, that will be resolved and connected.
TCP is the initial implementation so we an validate the
interfaces. UDP, Unix-Local and SSL will come later as derivate
classes.
The examples are documented and should cover the basic principles:
- efl_io_copier_example can accept "tcp://IP:PORT" and will work as a
"netcat", can send data from socket, file or stdin to a socket,
file, stdout or stderr.
- efl_net_server_example listens for connections and can either reply
"Hello World!" and take some data or work as an echo-server,
looping back all received data to the user.
More complex interactions that require a "chat" between client and
server will be covered with new classes later, such as a queue that
empties itself once data is read.
2016-08-17 21:53:16 -07:00
|
|
|
lib/ecore_con/efl_net_server_fd.eo \
|
2017-09-29 14:12:03 -07:00
|
|
|
lib/ecore_con/efl_net_server_ip.eo \
|
efl.net: socket, server and dialer for TCP.
Efl.Net.Server defines how to accept new connections, doing the
bind(), listen() and accept() for protocols such as TCP.
Efl.Net.Dialer defines to to reach a server.
Both are based on Efl.Net.Socket as communication interface that is
based on Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being
usable with code such as Efl.Io.Copier.
The Server will emit an event "client,add" with the established
Socket, which is a child and can be closed by both the server or the
user.
The Dialer extends the Socket and allows for creating one given an
address, that will be resolved and connected.
TCP is the initial implementation so we an validate the
interfaces. UDP, Unix-Local and SSL will come later as derivate
classes.
The examples are documented and should cover the basic principles:
- efl_io_copier_example can accept "tcp://IP:PORT" and will work as a
"netcat", can send data from socket, file or stdin to a socket,
file, stdout or stderr.
- efl_net_server_example listens for connections and can either reply
"Hello World!" and take some data or work as an echo-server,
looping back all received data to the user.
More complex interactions that require a "chat" between client and
server will be covered with new classes later, such as a queue that
empties itself once data is read.
2016-08-17 21:53:16 -07:00
|
|
|
lib/ecore_con/efl_net_server_tcp.eo \
|
2016-10-21 08:24:02 -07:00
|
|
|
lib/ecore_con/efl_net_server_udp.eo \
|
|
|
|
lib/ecore_con/efl_net_server_udp_client.eo \
|
2016-10-28 17:48:19 -07:00
|
|
|
lib/ecore_con/efl_net_socket_ssl.eo \
|
|
|
|
lib/ecore_con/efl_net_ssl_context.eo \
|
2016-10-31 20:31:56 -07:00
|
|
|
lib/ecore_con/efl_net_dialer_ssl.eo \
|
|
|
|
lib/ecore_con/efl_net_server_ssl.eo \
|
efl_net_session and efl_net_control for ConnMan
These are objects to allow control of networking devices
(efl_net_control) as well as an application to request for
connectivity (efl_net_session).
They are loosely based on ConnMan.org, which we already use in
Enlightenment Window Manager via DBus access with Eldbus. However they
do not map 1:1 as the goal was to expose a viable subset of controls
but in a simple and general way, thus nome strings were converted to
enums, some arrays of strings were converted to bitwise flags, some
names were made more general, such as "service" was turned into
"access point" so it doesn't generate confusion with other "network
services" (ie: http server), or "favorite" that was renamed to
"remembered". Some behavior are slightly different (yet able to be
implemented on top), such as "Service.MoveBefore" and "MoveAfter" were
converted to a numeric "priority", calculated from service's list
index, changing the priority will reoder the list and thus generate
the MoveBefore and MoveAfter DBus commands.
ConnMan was chosen not only because we already use it, but because its
DBus API is sane and simple, with the server doing almost all that we
need. This is visible in the efl_net_session, which is completely done
in the server and do not require any extra work on our side -- aside
from talking DBus and converting to Eo, which is a major work :-D
NOTE: ConnMan doesn't use FreeDesktop.Org DBus interfaces such as
Properties and ObjectManager, thus we cannot use
eldbus_model_object.
There are two examples added:
- efl_net_session_example: monitors the connection available for an
application and try to connect. You need a connman compiled with
session_policy_local and a configuration file explained in
https://github.com/aldebaran/connman/blob/master/doc/session-policy-format.txt
to get a connection if nothing is connected. Otherwise it will just
monitor the connectivity state.
- efl_net_control_example: monitors, plays the agent and configure
the network details. It can enable/disable technologies, connect to
access points (services) and configure them. It's quite extensive
as allows testing all of ConnMan's DBus API except P2P (Peers).
2016-09-15 17:43:19 -07:00
|
|
|
lib/ecore_con/efl_net_control_access_point.eo \
|
|
|
|
lib/ecore_con/efl_net_control_technology.eo \
|
2018-04-06 02:06:56 -07:00
|
|
|
lib/ecore_con/efl_net_control_manager.eo \
|
efl_net_session and efl_net_control for ConnMan
These are objects to allow control of networking devices
(efl_net_control) as well as an application to request for
connectivity (efl_net_session).
They are loosely based on ConnMan.org, which we already use in
Enlightenment Window Manager via DBus access with Eldbus. However they
do not map 1:1 as the goal was to expose a viable subset of controls
but in a simple and general way, thus nome strings were converted to
enums, some arrays of strings were converted to bitwise flags, some
names were made more general, such as "service" was turned into
"access point" so it doesn't generate confusion with other "network
services" (ie: http server), or "favorite" that was renamed to
"remembered". Some behavior are slightly different (yet able to be
implemented on top), such as "Service.MoveBefore" and "MoveAfter" were
converted to a numeric "priority", calculated from service's list
index, changing the priority will reoder the list and thus generate
the MoveBefore and MoveAfter DBus commands.
ConnMan was chosen not only because we already use it, but because its
DBus API is sane and simple, with the server doing almost all that we
need. This is visible in the efl_net_session, which is completely done
in the server and do not require any extra work on our side -- aside
from talking DBus and converting to Eo, which is a major work :-D
NOTE: ConnMan doesn't use FreeDesktop.Org DBus interfaces such as
Properties and ObjectManager, thus we cannot use
eldbus_model_object.
There are two examples added:
- efl_net_session_example: monitors the connection available for an
application and try to connect. You need a connman compiled with
session_policy_local and a configuration file explained in
https://github.com/aldebaran/connman/blob/master/doc/session-policy-format.txt
to get a connection if nothing is connected. Otherwise it will just
monitor the connectivity state.
- efl_net_control_example: monitors, plays the agent and configure
the network details. It can enable/disable technologies, connect to
access points (services) and configure them. It's quite extensive
as allows testing all of ConnMan's DBus API except P2P (Peers).
2016-09-15 17:43:19 -07:00
|
|
|
lib/ecore_con/efl_net_session.eo \
|
2016-12-11 20:23:29 -08:00
|
|
|
lib/ecore_con/efl_net_ip_address.eo \
|
2015-06-22 09:55:54 -07:00
|
|
|
lib/ecore_con/ecore_con_eet_base.eo \
|
|
|
|
lib/ecore_con/ecore_con_eet_server_obj.eo \
|
2016-11-28 21:43:16 -08:00
|
|
|
lib/ecore_con/ecore_con_eet_client_obj.eo
|
2014-10-02 08:52:45 -07:00
|
|
|
|
2016-10-26 13:57:37 -07:00
|
|
|
if HAVE_WINDOWS
|
implement efl_net_{socket,dialer,server}_windows
This is the local socket for windows, analogous to AF_UNIX.
`Efl_Net_Socket_Windows` is the base class doing `ReadFile()` and
`WriteFile()` using overlapped I/O, as well as the close procedure
(`FlushFileBuffers()`, `DisconnectNamedPipe()` and
`CloseHandle()`). These are done on top of an existing HANDLE that is
set by `Efl_Net_Dialer_Windows` (from `CreateFile()`) or
`Efl_Net_Server_Windows` (from `CreateNamedPipe()`).
The overlapped I/O will return immediately, either with operation
completed or `ERROR_IO_PENDING`, which means the kernel will execute
that asynchronously and will later `SetEvent(overlapped.hEvent)` which
is an event we wait on our main loop. That `overlapped` handle must
exist during the call lifetime, thus cannot be bound to `pd`, as we
may call `CancelIo()` but there is no guarantee the memory won't be
touched, in that case we keep the overlapped around, but without an
associated object.
Windows provides no notification "can read without blocking" or
non-blocking calls that returns partial data. The way to go is to use
these overlapped I/O, with an initial `ReadFile()` to an internal
buffer, once that operation finishes, we callback the user to says
there is something to read (`efl_io_reader_can_read_set()`) and wait
until `efl_io_reader_read()` is called to consume the available data,
then `ReadFile()` is called again to read more data to the same
internal buffer.
Likewise, there is no "can write without blocking" or non-blocking
calls that sends only partial data. The way to go is to get user bytes
in `efl_io_writer_write()` and copy them in an internal buffer, then
call `WriteFile()` on that and inform the user nothing else can be
written until that operation completes
(`efl_io_writer_can_write_set()`).
This is cumbersome since we say we "sent" stuff when we actually
didn't, it's still in our internal buffer (`pd->send.bytes`), but
nonetheless the kernel and the other peer may be adding even more
buffers, in this case we need to do a best effort to get it
delivery. A particular case is troublesome: `write() -> close()`, this
may result in `WriteFile()` pending, in this case we wait using
`GetOverlappedResult()`, *this is nasty and may block*, but it's the
only way I see to cope with such common use case.
Other operations, like ongoing `ReadFile()` or `ConnectNamedPipe()`
will be canceled using `CancelIo()`.
Q: Why no I/O Completion Port (IOCP) was used? Why no
CreateThreadpoolIo()? These perform much better!
A: These will call back from secondary threads, but in EFL we must
report back to the user in order to process incoming data or get
more data to send. That is, we serialize everything to the main
thread, making it impossible to use the benefits of IOCP and
similar such as CreateThreadpoolIo(). Since we'd need to wakeup the
main thread anyways, using `OVERLAPPED.hEvent` with
`ecore_main_win32_handler_add()` does the job as we expect.
Thanks to Vincent Torri (vtorri) for his help getting this code done
with an example on how to do the NamedPipe handling on Windows.
2017-03-22 00:29:16 -07:00
|
|
|
ecore_con_eolian_files += \
|
|
|
|
lib/ecore_con/efl_net_socket_windows.eo \
|
|
|
|
lib/ecore_con/efl_net_dialer_windows.eo \
|
|
|
|
lib/ecore_con/efl_net_server_windows.eo
|
2016-10-26 13:57:37 -07:00
|
|
|
else
|
|
|
|
ecore_con_eolian_files += \
|
|
|
|
lib/ecore_con/efl_net_socket_unix.eo \
|
|
|
|
lib/ecore_con/efl_net_dialer_unix.eo \
|
|
|
|
lib/ecore_con/efl_net_server_unix.eo
|
|
|
|
endif
|
|
|
|
|
2016-08-19 20:55:26 -07:00
|
|
|
ecore_con_eolian_type_files = \
|
2016-12-11 16:17:15 -08:00
|
|
|
lib/ecore_con/efl_net_types.eot \
|
2016-10-28 17:48:19 -07:00
|
|
|
lib/ecore_con/efl_net_http_types.eot \
|
|
|
|
lib/ecore_con/efl_net_ssl_types.eot
|
2016-08-19 20:55:26 -07:00
|
|
|
|
|
|
|
|
2014-10-02 08:52:45 -07:00
|
|
|
ecore_con_eolian_c = $(ecore_con_eolian_files:%.eo=%.eo.c)
|
|
|
|
ecore_con_eolian_h = $(ecore_con_eolian_files:%.eo=%.eo.h) \
|
2016-08-19 20:55:26 -07:00
|
|
|
$(ecore_con_eolian_type_files:%.eot=%.eot.h) \
|
2014-10-02 08:52:45 -07:00
|
|
|
$(ecore_con_eolian_files:%.eo=%.eo.legacy.h)
|
2014-08-22 05:14:59 -07:00
|
|
|
|
2014-08-22 03:11:41 -07:00
|
|
|
BUILT_SOURCES += \
|
2014-10-02 08:52:45 -07:00
|
|
|
$(ecore_con_eolian_c) \
|
|
|
|
$(ecore_con_eolian_h)
|
|
|
|
|
2014-08-22 03:11:41 -07:00
|
|
|
ecoreconeolianfilesdir = $(datadir)/eolian/include/ecore-@VMAJ@
|
|
|
|
ecoreconeolianfiles_DATA = \
|
2016-08-19 20:55:26 -07:00
|
|
|
$(ecore_con_eolian_files) \
|
|
|
|
$(ecore_con_eolian_type_files)
|
2014-08-22 03:11:41 -07:00
|
|
|
|
2016-06-08 01:26:06 -07:00
|
|
|
EXTRA_DIST2 += \
|
2014-08-22 03:11:41 -07:00
|
|
|
${ecoreconeolianfiles_DATA}
|
|
|
|
|
2016-08-19 20:55:26 -07:00
|
|
|
|
2012-12-02 14:35:45 -08:00
|
|
|
lib_LTLIBRARIES += lib/ecore_con/libecore_con.la
|
|
|
|
|
2013-01-16 11:28:30 -08:00
|
|
|
installed_ecoreconmainheadersdir = $(includedir)/ecore-con-@VMAJ@
|
2012-12-02 14:35:45 -08:00
|
|
|
dist_installed_ecoreconmainheaders_DATA = \
|
|
|
|
lib/ecore_con/Ecore_Con.h \
|
2017-10-27 18:48:16 -07:00
|
|
|
lib/ecore_con/Efl_Net.h \
|
2015-06-22 23:17:45 -07:00
|
|
|
lib/ecore_con/Ecore_Con_Eet.h \
|
|
|
|
lib/ecore_con/Ecore_Con_Eet_Legacy.h \
|
|
|
|
lib/ecore_con/Ecore_Con_Eet_Eo.h
|
2012-12-02 14:35:45 -08:00
|
|
|
|
2014-08-22 03:11:41 -07:00
|
|
|
nodist_installed_ecoreconmainheaders_DATA = \
|
2014-10-02 08:52:45 -07:00
|
|
|
$(ecore_con_eolian_h)
|
2014-08-22 03:11:41 -07:00
|
|
|
|
2012-12-02 14:35:45 -08:00
|
|
|
lib_ecore_con_libecore_con_la_SOURCES = \
|
|
|
|
lib/ecore_con/ecore_con_alloc.c \
|
|
|
|
lib/ecore_con/ecore_con.c \
|
2017-01-08 05:57:54 -08:00
|
|
|
lib/ecore_con/ecore_con_proxy_helper.c \
|
2016-12-07 07:34:28 -08:00
|
|
|
lib/ecore_con/ecore_con_legacy.c \
|
2012-12-02 14:35:45 -08:00
|
|
|
lib/ecore_con/ecore_con_eet.c \
|
|
|
|
lib/ecore_con/ecore_con_socks.c \
|
|
|
|
lib/ecore_con/ecore_con_url.c \
|
2015-09-02 20:22:01 -07:00
|
|
|
lib/ecore_con/ecore_con_url_curl.c \
|
|
|
|
lib/ecore_con/ecore_con_url_curl.h \
|
2015-11-09 15:52:11 -08:00
|
|
|
static_libs/http-parser/http_parser.c \
|
|
|
|
static_libs/http-parser/http_parser.h \
|
ecore-con - simplify down to a single libc resolver
Summary:
this removes the cares/ares based resolver and the compiled-in dns.c
resolver, modified the getaddrinfo based resolver to use threads not
forking (almost halving its size) and now makes that the only resolver
we have. getaddrinfo handles ipv6 and ipv4 (according to docs). this
simplifies code paths, drops code size of the efl tree by about 11k
lines of code, makes it easier to test and more robust to future
changes with ip resolving as it now just relies on libc. we won't have
coverity complaints on dns.c imported code anymore to fix and don't
have tokeep up with bugfixes/security from the upstream imported code.
this means we use a single resolver on all platforms (windows, mac,
linux) as opposed to before where cares was used for windows, and
dns.c on linux/mac. oh and the forking original was broken since our
move to eo too. so it couldnt even compile if enabled, letalone work.
so fix bug with missing /etc/resolv.conf that dns.c couldn't cope
with, fix testability, fix maintainability and reduce efl codebase size.
this fixes T3668
@fix
@improve
Subscribers: cedric, seoz, jpeg
Maniphest Tasks: T3668
Differential Revision: https://phab.enlightenment.org/D3971
2016-05-22 01:03:26 -07:00
|
|
|
lib/ecore_con/ecore_con_private.h \
|
efl.net: socket, server and dialer for TCP.
Efl.Net.Server defines how to accept new connections, doing the
bind(), listen() and accept() for protocols such as TCP.
Efl.Net.Dialer defines to to reach a server.
Both are based on Efl.Net.Socket as communication interface that is
based on Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being
usable with code such as Efl.Io.Copier.
The Server will emit an event "client,add" with the established
Socket, which is a child and can be closed by both the server or the
user.
The Dialer extends the Socket and allows for creating one given an
address, that will be resolved and connected.
TCP is the initial implementation so we an validate the
interfaces. UDP, Unix-Local and SSL will come later as derivate
classes.
The examples are documented and should cover the basic principles:
- efl_io_copier_example can accept "tcp://IP:PORT" and will work as a
"netcat", can send data from socket, file or stdin to a socket,
file, stdout or stderr.
- efl_net_server_example listens for connections and can either reply
"Hello World!" and take some data or work as an echo-server,
looping back all received data to the user.
More complex interactions that require a "chat" between client and
server will be covered with new classes later, such as a queue that
empties itself once data is read.
2016-08-17 21:53:16 -07:00
|
|
|
lib/ecore_con/efl_net_socket.c \
|
efl_net_{socket,dialer,server}_simple: easy to use, buffered network sockets.
The low level I/O primitives are powerful but adds some complexity to
use, for bi-directional streaming communication one ends creating two
Efl.Io.Queue and two Efl.Io.Copier to pipe data to socket when it can
operate.
Then encapsulate the socket using the new Efl.Io.Buffered_Stream, this
will allow the socket, be a dialer or a server client, to be operated
as a single handle that internally carries about the buffering for
you.
As one can see in the examples, compared to their "manual"
alternatives they are very easy to use, ressembling
Ecore_Con_Server/Ecore_Con_Client, but also offers line-based
delimiters and the possibility to let the socket to handle queueing
for you in case you received partial messages (just do not
read/clear/discard the received data).
2016-11-25 11:18:34 -08:00
|
|
|
lib/ecore_con/efl_net_socket_simple.c \
|
efl.net: socket, server and dialer for TCP.
Efl.Net.Server defines how to accept new connections, doing the
bind(), listen() and accept() for protocols such as TCP.
Efl.Net.Dialer defines to to reach a server.
Both are based on Efl.Net.Socket as communication interface that is
based on Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being
usable with code such as Efl.Io.Copier.
The Server will emit an event "client,add" with the established
Socket, which is a child and can be closed by both the server or the
user.
The Dialer extends the Socket and allows for creating one given an
address, that will be resolved and connected.
TCP is the initial implementation so we an validate the
interfaces. UDP, Unix-Local and SSL will come later as derivate
classes.
The examples are documented and should cover the basic principles:
- efl_io_copier_example can accept "tcp://IP:PORT" and will work as a
"netcat", can send data from socket, file or stdin to a socket,
file, stdout or stderr.
- efl_net_server_example listens for connections and can either reply
"Hello World!" and take some data or work as an echo-server,
looping back all received data to the user.
More complex interactions that require a "chat" between client and
server will be covered with new classes later, such as a queue that
empties itself once data is read.
2016-08-17 21:53:16 -07:00
|
|
|
lib/ecore_con/efl_net_socket_fd.c \
|
|
|
|
lib/ecore_con/efl_net_socket_tcp.c \
|
2016-10-18 13:51:59 -07:00
|
|
|
lib/ecore_con/efl_net_socket_udp.c \
|
efl.net: socket, server and dialer for TCP.
Efl.Net.Server defines how to accept new connections, doing the
bind(), listen() and accept() for protocols such as TCP.
Efl.Net.Dialer defines to to reach a server.
Both are based on Efl.Net.Socket as communication interface that is
based on Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being
usable with code such as Efl.Io.Copier.
The Server will emit an event "client,add" with the established
Socket, which is a child and can be closed by both the server or the
user.
The Dialer extends the Socket and allows for creating one given an
address, that will be resolved and connected.
TCP is the initial implementation so we an validate the
interfaces. UDP, Unix-Local and SSL will come later as derivate
classes.
The examples are documented and should cover the basic principles:
- efl_io_copier_example can accept "tcp://IP:PORT" and will work as a
"netcat", can send data from socket, file or stdin to a socket,
file, stdout or stderr.
- efl_net_server_example listens for connections and can either reply
"Hello World!" and take some data or work as an echo-server,
looping back all received data to the user.
More complex interactions that require a "chat" between client and
server will be covered with new classes later, such as a queue that
empties itself once data is read.
2016-08-17 21:53:16 -07:00
|
|
|
lib/ecore_con/efl_net_dialer.c \
|
efl_net_{socket,dialer,server}_simple: easy to use, buffered network sockets.
The low level I/O primitives are powerful but adds some complexity to
use, for bi-directional streaming communication one ends creating two
Efl.Io.Queue and two Efl.Io.Copier to pipe data to socket when it can
operate.
Then encapsulate the socket using the new Efl.Io.Buffered_Stream, this
will allow the socket, be a dialer or a server client, to be operated
as a single handle that internally carries about the buffering for
you.
As one can see in the examples, compared to their "manual"
alternatives they are very easy to use, ressembling
Ecore_Con_Server/Ecore_Con_Client, but also offers line-based
delimiters and the possibility to let the socket to handle queueing
for you in case you received partial messages (just do not
read/clear/discard the received data).
2016-11-25 11:18:34 -08:00
|
|
|
lib/ecore_con/efl_net_dialer_simple.c \
|
efl.net: socket, server and dialer for TCP.
Efl.Net.Server defines how to accept new connections, doing the
bind(), listen() and accept() for protocols such as TCP.
Efl.Net.Dialer defines to to reach a server.
Both are based on Efl.Net.Socket as communication interface that is
based on Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being
usable with code such as Efl.Io.Copier.
The Server will emit an event "client,add" with the established
Socket, which is a child and can be closed by both the server or the
user.
The Dialer extends the Socket and allows for creating one given an
address, that will be resolved and connected.
TCP is the initial implementation so we an validate the
interfaces. UDP, Unix-Local and SSL will come later as derivate
classes.
The examples are documented and should cover the basic principles:
- efl_io_copier_example can accept "tcp://IP:PORT" and will work as a
"netcat", can send data from socket, file or stdin to a socket,
file, stdout or stderr.
- efl_net_server_example listens for connections and can either reply
"Hello World!" and take some data or work as an echo-server,
looping back all received data to the user.
More complex interactions that require a "chat" between client and
server will be covered with new classes later, such as a queue that
empties itself once data is read.
2016-08-17 21:53:16 -07:00
|
|
|
lib/ecore_con/efl_net_dialer_tcp.c \
|
2016-10-18 13:51:59 -07:00
|
|
|
lib/ecore_con/efl_net_dialer_udp.c \
|
2016-08-19 20:55:26 -07:00
|
|
|
lib/ecore_con/efl_net_dialer_http.c \
|
2016-08-29 20:28:00 -07:00
|
|
|
lib/ecore_con/efl_net_dialer_websocket.c \
|
efl.net: socket, server and dialer for TCP.
Efl.Net.Server defines how to accept new connections, doing the
bind(), listen() and accept() for protocols such as TCP.
Efl.Net.Dialer defines to to reach a server.
Both are based on Efl.Net.Socket as communication interface that is
based on Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being
usable with code such as Efl.Io.Copier.
The Server will emit an event "client,add" with the established
Socket, which is a child and can be closed by both the server or the
user.
The Dialer extends the Socket and allows for creating one given an
address, that will be resolved and connected.
TCP is the initial implementation so we an validate the
interfaces. UDP, Unix-Local and SSL will come later as derivate
classes.
The examples are documented and should cover the basic principles:
- efl_io_copier_example can accept "tcp://IP:PORT" and will work as a
"netcat", can send data from socket, file or stdin to a socket,
file, stdout or stderr.
- efl_net_server_example listens for connections and can either reply
"Hello World!" and take some data or work as an echo-server,
looping back all received data to the user.
More complex interactions that require a "chat" between client and
server will be covered with new classes later, such as a queue that
empties itself once data is read.
2016-08-17 21:53:16 -07:00
|
|
|
lib/ecore_con/efl_net_server.c \
|
efl_net_{socket,dialer,server}_simple: easy to use, buffered network sockets.
The low level I/O primitives are powerful but adds some complexity to
use, for bi-directional streaming communication one ends creating two
Efl.Io.Queue and two Efl.Io.Copier to pipe data to socket when it can
operate.
Then encapsulate the socket using the new Efl.Io.Buffered_Stream, this
will allow the socket, be a dialer or a server client, to be operated
as a single handle that internally carries about the buffering for
you.
As one can see in the examples, compared to their "manual"
alternatives they are very easy to use, ressembling
Ecore_Con_Server/Ecore_Con_Client, but also offers line-based
delimiters and the possibility to let the socket to handle queueing
for you in case you received partial messages (just do not
read/clear/discard the received data).
2016-11-25 11:18:34 -08:00
|
|
|
lib/ecore_con/efl_net_server_simple.c \
|
efl.net: socket, server and dialer for TCP.
Efl.Net.Server defines how to accept new connections, doing the
bind(), listen() and accept() for protocols such as TCP.
Efl.Net.Dialer defines to to reach a server.
Both are based on Efl.Net.Socket as communication interface that is
based on Efl.Io.Reader, Efl.Io.Writer and Efl.Io.Closer, thus being
usable with code such as Efl.Io.Copier.
The Server will emit an event "client,add" with the established
Socket, which is a child and can be closed by both the server or the
user.
The Dialer extends the Socket and allows for creating one given an
address, that will be resolved and connected.
TCP is the initial implementation so we an validate the
interfaces. UDP, Unix-Local and SSL will come later as derivate
classes.
The examples are documented and should cover the basic principles:
- efl_io_copier_example can accept "tcp://IP:PORT" and will work as a
"netcat", can send data from socket, file or stdin to a socket,
file, stdout or stderr.
- efl_net_server_example listens for connections and can either reply
"Hello World!" and take some data or work as an echo-server,
looping back all received data to the user.
More complex interactions that require a "chat" between client and
server will be covered with new classes later, such as a queue that
empties itself once data is read.
2016-08-17 21:53:16 -07:00
|
|
|
lib/ecore_con/efl_net_server_fd.c \
|
2017-09-29 14:12:03 -07:00
|
|
|
lib/ecore_con/efl_net_server_ip.c \
|
2016-10-21 08:24:02 -07:00
|
|
|
lib/ecore_con/efl_net_server_tcp.c \
|
|
|
|
lib/ecore_con/efl_net_server_udp.c \
|
2016-10-28 17:48:19 -07:00
|
|
|
lib/ecore_con/efl_net_server_udp_client.c \
|
|
|
|
lib/ecore_con/efl_net_socket_ssl.c \
|
2016-10-31 20:31:56 -07:00
|
|
|
lib/ecore_con/efl_net_ssl_context.c \
|
|
|
|
lib/ecore_con/efl_net_dialer_ssl.c \
|
2016-12-07 07:34:28 -08:00
|
|
|
lib/ecore_con/efl_net_server_ssl.c \
|
2016-12-11 20:23:29 -08:00
|
|
|
lib/ecore_con/ecore_con_local.c \
|
2018-02-16 11:37:17 -08:00
|
|
|
lib/ecore_con/efl_net_ip_address.c \
|
|
|
|
static_libs/buildsystem/buildsystem.h \
|
|
|
|
static_libs/buildsystem/buildsystem_autotools.c
|
2016-11-18 12:11:51 -08:00
|
|
|
|
|
|
|
if EFL_NET_CONTROL_BACKEND_CONNMAN
|
|
|
|
lib_ecore_con_libecore_con_la_SOURCES += \
|
efl_net_session and efl_net_control for ConnMan
These are objects to allow control of networking devices
(efl_net_control) as well as an application to request for
connectivity (efl_net_session).
They are loosely based on ConnMan.org, which we already use in
Enlightenment Window Manager via DBus access with Eldbus. However they
do not map 1:1 as the goal was to expose a viable subset of controls
but in a simple and general way, thus nome strings were converted to
enums, some arrays of strings were converted to bitwise flags, some
names were made more general, such as "service" was turned into
"access point" so it doesn't generate confusion with other "network
services" (ie: http server), or "favorite" that was renamed to
"remembered". Some behavior are slightly different (yet able to be
implemented on top), such as "Service.MoveBefore" and "MoveAfter" were
converted to a numeric "priority", calculated from service's list
index, changing the priority will reoder the list and thus generate
the MoveBefore and MoveAfter DBus commands.
ConnMan was chosen not only because we already use it, but because its
DBus API is sane and simple, with the server doing almost all that we
need. This is visible in the efl_net_session, which is completely done
in the server and do not require any extra work on our side -- aside
from talking DBus and converting to Eo, which is a major work :-D
NOTE: ConnMan doesn't use FreeDesktop.Org DBus interfaces such as
Properties and ObjectManager, thus we cannot use
eldbus_model_object.
There are two examples added:
- efl_net_session_example: monitors the connection available for an
application and try to connect. You need a connman compiled with
session_policy_local and a configuration file explained in
https://github.com/aldebaran/connman/blob/master/doc/session-policy-format.txt
to get a connection if nothing is connected. Otherwise it will just
monitor the connectivity state.
- efl_net_control_example: monitors, plays the agent and configure
the network details. It can enable/disable technologies, connect to
access points (services) and configure them. It's quite extensive
as allows testing all of ConnMan's DBus API except P2P (Peers).
2016-09-15 17:43:19 -07:00
|
|
|
lib/ecore_con/efl_net-connman.h \
|
|
|
|
lib/ecore_con/efl_net-connman.c \
|
|
|
|
lib/ecore_con/efl_net_control_access_point-connman.c \
|
|
|
|
lib/ecore_con/efl_net_control_technology-connman.c \
|
|
|
|
lib/ecore_con/efl_net_control-connman.c \
|
|
|
|
lib/ecore_con/efl_net_session-connman.c
|
2016-11-18 12:11:51 -08:00
|
|
|
endif
|
|
|
|
|
|
|
|
if EFL_NET_CONTROL_BACKEND_NONE
|
|
|
|
lib_ecore_con_libecore_con_la_SOURCES += \
|
|
|
|
lib/ecore_con/efl_net_control_access_point-none.c \
|
|
|
|
lib/ecore_con/efl_net_control_technology-none.c \
|
|
|
|
lib/ecore_con/efl_net_control-none.c \
|
|
|
|
lib/ecore_con/efl_net_session-none.c
|
|
|
|
endif
|
2012-12-02 14:35:45 -08:00
|
|
|
|
2016-10-28 17:48:19 -07:00
|
|
|
# these are included rather than compiled out
|
|
|
|
# so the structures can be embedded into the
|
|
|
|
# object Private Data and allows functions to
|
|
|
|
# be all static
|
|
|
|
EXTRA_DIST2 += \
|
|
|
|
lib/ecore_con/efl_net_ssl_conn-openssl.c \
|
|
|
|
lib/ecore_con/efl_net_ssl_conn-gnutls.c \
|
|
|
|
lib/ecore_con/efl_net_ssl_conn-none.c \
|
|
|
|
lib/ecore_con/efl_net_ssl_ctx-openssl.c \
|
|
|
|
lib/ecore_con/efl_net_ssl_ctx-gnutls.c \
|
|
|
|
lib/ecore_con/efl_net_ssl_ctx-none.c
|
|
|
|
|
2012-12-02 14:35:45 -08:00
|
|
|
if HAVE_WINDOWS
|
implement efl_net_{socket,dialer,server}_windows
This is the local socket for windows, analogous to AF_UNIX.
`Efl_Net_Socket_Windows` is the base class doing `ReadFile()` and
`WriteFile()` using overlapped I/O, as well as the close procedure
(`FlushFileBuffers()`, `DisconnectNamedPipe()` and
`CloseHandle()`). These are done on top of an existing HANDLE that is
set by `Efl_Net_Dialer_Windows` (from `CreateFile()`) or
`Efl_Net_Server_Windows` (from `CreateNamedPipe()`).
The overlapped I/O will return immediately, either with operation
completed or `ERROR_IO_PENDING`, which means the kernel will execute
that asynchronously and will later `SetEvent(overlapped.hEvent)` which
is an event we wait on our main loop. That `overlapped` handle must
exist during the call lifetime, thus cannot be bound to `pd`, as we
may call `CancelIo()` but there is no guarantee the memory won't be
touched, in that case we keep the overlapped around, but without an
associated object.
Windows provides no notification "can read without blocking" or
non-blocking calls that returns partial data. The way to go is to use
these overlapped I/O, with an initial `ReadFile()` to an internal
buffer, once that operation finishes, we callback the user to says
there is something to read (`efl_io_reader_can_read_set()`) and wait
until `efl_io_reader_read()` is called to consume the available data,
then `ReadFile()` is called again to read more data to the same
internal buffer.
Likewise, there is no "can write without blocking" or non-blocking
calls that sends only partial data. The way to go is to get user bytes
in `efl_io_writer_write()` and copy them in an internal buffer, then
call `WriteFile()` on that and inform the user nothing else can be
written until that operation completes
(`efl_io_writer_can_write_set()`).
This is cumbersome since we say we "sent" stuff when we actually
didn't, it's still in our internal buffer (`pd->send.bytes`), but
nonetheless the kernel and the other peer may be adding even more
buffers, in this case we need to do a best effort to get it
delivery. A particular case is troublesome: `write() -> close()`, this
may result in `WriteFile()` pending, in this case we wait using
`GetOverlappedResult()`, *this is nasty and may block*, but it's the
only way I see to cope with such common use case.
Other operations, like ongoing `ReadFile()` or `ConnectNamedPipe()`
will be canceled using `CancelIo()`.
Q: Why no I/O Completion Port (IOCP) was used? Why no
CreateThreadpoolIo()? These perform much better!
A: These will call back from secondary threads, but in EFL we must
report back to the user in order to process incoming data or get
more data to send. That is, we serialize everything to the main
thread, making it impossible to use the benefits of IOCP and
similar such as CreateThreadpoolIo(). Since we'd need to wakeup the
main thread anyways, using `OVERLAPPED.hEvent` with
`ecore_main_win32_handler_add()` does the job as we expect.
Thanks to Vincent Torri (vtorri) for his help getting this code done
with an example on how to do the NamedPipe handling on Windows.
2017-03-22 00:29:16 -07:00
|
|
|
lib_ecore_con_libecore_con_la_SOURCES += \
|
|
|
|
lib/ecore_con/efl_net_socket_windows.c \
|
|
|
|
lib/ecore_con/efl_net_dialer_windows.c \
|
|
|
|
lib/ecore_con/efl_net_server_windows.c
|
2012-12-02 14:35:45 -08:00
|
|
|
else
|
2016-12-07 07:34:28 -08:00
|
|
|
lib_ecore_con_libecore_con_la_SOURCES += \
|
2016-10-26 13:57:37 -07:00
|
|
|
lib/ecore_con/efl_net_socket_unix.c \
|
|
|
|
lib/ecore_con/efl_net_dialer_unix.c \
|
|
|
|
lib/ecore_con/efl_net_server_unix.c
|
2012-12-02 14:35:45 -08:00
|
|
|
endif
|
|
|
|
|
2017-01-08 05:57:54 -08:00
|
|
|
lib_ecore_con_libecore_con_la_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
|
|
|
|
-DPACKAGE_BIN_DIR=\"$(bindir)\" \
|
|
|
|
-DPACKAGE_LIB_DIR=\"$(libdir)\" \
|
|
|
|
-DPACKAGE_DATA_DIR=\"$(datadir)/ecore\" \
|
|
|
|
-DPACKAGE_BUILD_DIR=\"$(abs_top_builddir)\" \
|
2018-02-16 11:37:17 -08:00
|
|
|
-DPACKAGE_SRC_DIR=\"$(abs_top_srcdir)\" \
|
2017-01-08 05:57:54 -08:00
|
|
|
@ECORE_CON_CFLAGS@
|
2014-05-15 19:26:53 -07:00
|
|
|
lib_ecore_con_libecore_con_la_LIBADD = @ECORE_CON_LIBS@ @EVIL_LIBS@
|
2013-01-14 14:36:23 -08:00
|
|
|
lib_ecore_con_libecore_con_la_DEPENDENCIES = @ECORE_CON_INTERNAL_LIBS@
|
2012-12-30 14:15:29 -08:00
|
|
|
lib_ecore_con_libecore_con_la_LDFLAGS = @EFL_LTLIBRARY_FLAGS@
|
2014-10-06 03:32:25 -07:00
|
|
|
|
2015-11-09 15:52:11 -08:00
|
|
|
lib_ecore_con_libecore_con_la_CPPFLAGS += -I$(top_srcdir)/src/static_libs/http-parser
|
|
|
|
|
2016-06-08 01:26:06 -07:00
|
|
|
EXTRA_DIST2 += \
|
2015-04-07 04:17:25 -07:00
|
|
|
tests/ecore_con/server.key \
|
2015-11-09 15:52:11 -08:00
|
|
|
tests/ecore_con/server.pem \
|
|
|
|
static_libs/http-parser/AUTHORS \
|
|
|
|
static_libs/http-parser/CONTRIBUTIONS \
|
|
|
|
static_libs/http-parser/README.md \
|
|
|
|
static_libs/http-parser/test.c \
|
|
|
|
static_libs/http-parser/contrib/parsertrace.c \
|
|
|
|
static_libs/http-parser/contrib/url_parser.c
|
2015-04-07 04:17:25 -07:00
|
|
|
|
2017-01-08 05:57:54 -08:00
|
|
|
### Binary
|
|
|
|
proxyhelperdir = \
|
|
|
|
$(libdir)/ecore_con/utils/$(MODULE_ARCH)
|
|
|
|
proxyhelper_PROGRAMS = bin/ecore_con/efl_net_proxy_helper
|
|
|
|
|
|
|
|
bin_ecore_con_efl_net_proxy_helper_SOURCES = \
|
|
|
|
bin/ecore_con/efl_net_proxy_helper.c
|
|
|
|
|
|
|
|
bin_ecore_con_efl_net_proxy_helper_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
|
|
|
|
-DPACKAGE_BIN_DIR=\"$(bindir)\" \
|
|
|
|
-DPACKAGE_LIB_DIR=\"$(libdir)\" \
|
|
|
|
-DPACKAGE_DATA_DIR=\"$(datadir)/ecore\" \
|
|
|
|
@EINA_CFLAGS@
|
|
|
|
bin_ecore_con_efl_net_proxy_helper_LDADD = @USE_EINA_LIBS@
|
2017-02-09 14:42:14 -08:00
|
|
|
bin_ecore_con_efl_net_proxy_helper_DEPENDENCIES = @USE_EINA_INTERNAL_LIBS@
|
2017-01-08 05:57:54 -08:00
|
|
|
|
2015-04-06 06:59:10 -07:00
|
|
|
### Unit tests
|
|
|
|
|
|
|
|
if EFL_ENABLE_TESTS
|
|
|
|
|
|
|
|
check_PROGRAMS += tests/ecore_con/ecore_con_suite
|
|
|
|
TESTS += tests/ecore_con/ecore_con_suite
|
|
|
|
|
|
|
|
tests_ecore_con_ecore_con_suite_SOURCES = \
|
|
|
|
tests/ecore_con/ecore_con_suite.c \
|
|
|
|
tests/ecore_con/ecore_con_test_ecore_con.c \
|
|
|
|
tests/ecore_con/ecore_con_test_ecore_con_url.c \
|
2015-04-15 05:50:03 -07:00
|
|
|
tests/ecore_con/ecore_con_test_ecore_con_eet.c \
|
2016-12-11 20:23:29 -08:00
|
|
|
tests/ecore_con/ecore_con_test_efl_net_ip_address.c \
|
2015-04-06 06:59:10 -07:00
|
|
|
tests/ecore_con/ecore_con_suite.h
|
|
|
|
|
|
|
|
tests_ecore_con_ecore_con_suite_CPPFLAGS = -I$(top_builddir)/src/lib/efl \
|
|
|
|
-DTESTS_SRC_DIR=\"$(top_srcdir)/src/tests/ecore_con\" \
|
|
|
|
-DTESTS_BUILD_DIR=\"$(top_builddir)/src/tests/ecore_con\" \
|
|
|
|
@CHECK_CFLAGS@ \
|
|
|
|
@ECORE_CFLAGS@ \
|
|
|
|
@ECORE_CON_CFLAGS@
|
|
|
|
|
|
|
|
tests_ecore_con_ecore_con_suite_LDADD = \
|
|
|
|
@CHECK_LIBS@ \
|
|
|
|
@USE_ECORE_LIBS@ \
|
|
|
|
@USE_ECORE_CON_LIBS@
|
|
|
|
|
|
|
|
tests_ecore_con_ecore_con_suite_DEPENDENCIES = \
|
|
|
|
@USE_ECORE_INTERNAL_LIBS@ \
|
|
|
|
@USE_ECORE_CON_INTERNAL_LIBS@
|
|
|
|
|
|
|
|
endif
|
|
|
|
|
2014-10-06 03:32:25 -07:00
|
|
|
if HAVE_ELUA
|
|
|
|
|
|
|
|
ecore_con_eolian_lua = $(ecore_con_eolian_files:%.eo=%.eo.lua)
|
|
|
|
|
|
|
|
generated_ecore_con_lua_all = $(ecore_con_eolian_lua)
|
|
|
|
|
2016-06-21 07:13:17 -07:00
|
|
|
GENERATED_LUA_BINDINGS += $(generated_ecore_con_lua_all)
|
2014-10-06 03:32:25 -07:00
|
|
|
|
|
|
|
installed_ecoreconluadir = $(datadir)/elua/modules/ecore_con
|
|
|
|
nodist_installed_ecoreconlua_DATA = $(generated_ecore_con_lua_all)
|
|
|
|
|
|
|
|
endif
|
2014-09-01 11:08:49 -07:00
|
|
|
|
|
|
|
if HAVE_JS
|
|
|
|
|
|
|
|
generated_ecore_con_js_bindings = $(ecore_con_eolian_files:%.eo=%.eo.js.cc)
|
|
|
|
|
|
|
|
GENERATED_JS_BINDINGS += $(generated_ecore_con_js_bindings)
|
|
|
|
|
|
|
|
endif
|