|Age||Commit message (Collapse)||Author|
Reviewed-by: Daniel Kolesa <firstname.lastname@example.org>
Reviewed-by: Xavi Artigas <email@example.com>
Differential Revision: https://phab.enlightenment.org/D7684
As discussed in T7204:
- Eo Interfaces/mixins -> C# Interfaces with concrete class
- Eo Regular/Abstracts -> Proper C# classes
- Added some new generators and helper methods.
- Refactored the class generator, splitting into helper methods
Eo handles now are stored only in the "root" class in any given
inheritance tree (generally, Efl.Object), and accessible to each child.
Methods also are defined in a single place instead of repeatedly
generated in everyfile, reducing the size of the generated .dll from
30MB to around 4.5MB.
Mixins are generated as C# interfaces but any regular class it inherits
from is lost, as we can't have interfaces inheriting from regular
classes. This will be dealt with in a later commit.
Summary of API Changes:
- Merged Inherit/Concrete classes. (These suffixes disappear from
- Interface still have implementations with 'Concrete' suffix for when
they are returned from methods.
- Removed 'I' from interface names.
- Removed interfaces for regular/abstract Eo classes.
- Concrete classes for interfaces/mixins hold the event argument struct.
- Removed '_' from classes, enums, structs, etc, as indicated in C#
- Namespaces are now Camel.Cased.
- Renamed IWrapper's raw_handle/raw_klass to NativeHandle/NativeClass
Also renamed the test classes as after the namespace change, the
test namespace Test can conflict with the helper Test namespace.
(And use more meaningful names than Test.Testing...)
Also Fixes T7336 by removing a deprecated example and adding
efl_loop_timer_example to build system.
Fixes T7451 by hiding the class_get DllImports and renaming the IWrapper
fields. The native handlers are used in the manual binding.
Still need to work:
- As there are still some events names clashing (e.g. Efl.Ui.Bg with "resize"
from Efl.Gfx.Entity and Efl.Gfx.Image), Events are currently declared on
the interface and implemented "namespaced" in the classes,
requiring the cast to the interface to access the event.
- The Mixin Conundrum. Mixin inheritance will be dealt in a future
Depends on D7260
Reviewers: segfaultxavi, vitor.sousa, felipealmeida, Jaehyun_Cho
Reviewed By: vitor.sousa
Subscribers: cedric, #reviewers, #committers
Maniphest Tasks: T7451, T7336
Differential Revision: https://phab.enlightenment.org/D7262
this greatly improves build times by improving parallelizing, though it
does introduce more BUILT_SOURCES usage which causes builds with cxx
bindings to take significantly longer
Differential Revision: https://phab.enlightenment.org/D6633
Separated from the generator and libs for easier review
Depends on D6050
Reviewers: felipealmeida, vitor.sousa
Reviewed By: vitor.sousa
Differential Revision: https://phab.enlightenment.org/D6051
The examples were either not build or using repeated rules due to
_EOLIAN_DEP_GEN not being set correctly was Makefile_Eolian_Helper.am
assumes it being inclueded from src/, while each example folder has its
own .am inside its folder.
- Export required sources
- Avoid generated sources being passed as static ones
This will help in the transition from Autotools to Meson. This has been
tested on Windows for which EFL_XXX_BUILD were first introduced.
This commit adds the "documentation" generator, which gets the
documentation_def attribute of the given item and generates xml comments
to be exported by MCS.
For items requiring some customization of the generated comments (e.g.
functions and its parameters), the helpers to generate the preamble
(summary), body (paragraphs) and epilogue (currently just the @since
tag) were added.
Currently we do not support converting Eolian references into xmldoc
As we explicitly generate Get/Set methods for properties, for now the
generator tries to get the get/set specific documentation first. If it
is not present, fallback to the common docs.
Later this could be changed to generate the common one as paragraphs of
Also some generated code like the wrappers for calling C# methods
from C can be private. This will cleanup the introspection results
and warnings when generating documentation.
Due to this visibility change, the binbuf tests had to be changed
to add redirect calls to the native methods instead of directly
calling the DllImport'd methods.
Buildsystem support will be enabled in a future commit