Summary:
commit 74b56eedd1 added these to clean,
but the variable contains some non-generated files.
Turns out these files don't have to be part of the build at all, as
the tests that use them generate them in temp dirs.
Just remove the variable entirely.
Reviewers: bu5hm4n, zmike, q66
Reviewed By: bu5hm4n, zmike, q66
Subscribers: cedric, #reviewers, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6850
Summary:
this needs to be consistent so that it can be used reliably across suites
also these build flags really need to be consolidated into a single variable
that can be reused
Depends on D6666
Reviewers: devilhorns, bu5hm4n
Reviewed By: bu5hm4n
Subscribers: bu5hm4n, cedric, #committers
Tags: #efl_build
Differential Revision: https://phab.enlightenment.org/D6731
fix the naming for these targets based on automake 1.16+ presence and
naming scheme
ref D6594
fix T7154
Differential Revision: https://phab.enlightenment.org/D6675
Summary:
<q66> just remove decl.eo and remove the eolian_decl test; it's useless
<q66> the reason: it used to be testing some specific API, which got replaced with more generalized API that is now used everywhere in the tests, so that specific test no longer has a purpose
resolves some compile errors due to type conflicts
Reviewers: q66
Reviewed By: q66
Subscribers: cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6773
automake 1.16 changed the naming of object files:
- When subdir-objects is in effect, Automake will now construct
shorter object file names when no programs and libraries name
clashes are encountered. This should make the discouraged use of
'foo_SHORTNAME' unnecessary in many cases.
https://lists.gnu.org/archive/html/info-gnu/2018-02/msg00008.html
this requires that object-specific rules must be changed to match the new
naming scheme if newer automake is being used. the $am__api_version contains
the version string of the automake version used during autoreconf, so this
should be checked during configure time in order to generate the correct
makefile rule for that automake version
other similar rules should be changed in the same way
note that this conditional speculates on behavior of automake versions past
1.16, which are not yet released and thus may change, meaning that this issue may
reoccur in future automake versions
Differential Revision: https://phab.enlightenment.org/D6594
This adds code to run the Eolian static checker as part of tests,
but considering how many failures there are at this point, does
not enable it. Once they're all fixed, it can be enabled by
removing the #if 0.
Summary:
- Added missing C++ header
- Added missing elementary header
- Removed generated header from elementary_SOURCES
(Was added by raster in 42dfee37)
Not sure of what would be the best place for it, though.
- Removed previously removed files from elementary examples Makefile.
Test Plan: Run 'make distcheck'
Reviewers: stefan, felipealmeida
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D5800
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
Future is the read only side of a Promise. For now, I am not removing
Eina_Promise until everything is in place, but eventually the promise
type of eolian will be gone.
This is again to avoid the "Argument list too long" error we are hitting more and
more now. Given we just merged elementary, emotion generic players, evas generic
loaders and elm_code it is not surprising we are hitting it again.
This time the number of files being hold in DISTFILES has just grown to big so a
make dist was no longer possible. If one looks at what the DISTFILES variable
from automake holds you can image it grows a lot with all the source files plus
generated files we have in tree now.
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
To cut off a big chunk but still keep all the other automagic in place for
SOURCE files I went and renamed the EXTRA_DIST in src/ to EXTRA_DIST2 and handle
the files in a dist-hook now.
Another thing to note here is that this also only happens as we have the one big
Makefile with includes. If we go back to per directory Makefiles this problem
should vanish as well. In any case we need a solution for 1.18 now and this is
what I have to offer. If you have a cleaner solution in mind feel welcome to
test it out and if everything we need keeps working (make, make examples,
make check, make benchmark, make dist and make distcheck) go ahead.
Add a promise object to allows Eolian interface to include promises
as a way to have asynchronous value return and composibility.
The usage is like this in a .eo file:
class Foo {
methods {
bar {
params {
@inout promise: Promise<int>;
}
}
}
}
Which will create the following API interface:
void foo_bar(Eo* obj, Eina_Promise** promise);
and a Eina_Promise_Owner for the implementation, like this:
void _foo_bar(Eo* obj, Private_Data* pdata, Eina_Promise_Owner* promise);
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
While we had the functionality to generate type stubs header we never had
these tested in our unit test setup. Adding to simple cases for struct
and typedef which we already use for normal header generation tests.
This commit adds the necessary generator logic to emit doc
comments from the new doc syntax. Old doc comments are kept
in for the time being as they're used within the EFL but they
will be removed eventually. This new generator focuses all the
important code in one place, making usage easy.
@feature
This reverts commit 35119e7bfd.
Reverted to bring make check back in a working state. Also the way we
want to handle a more modular testing needs discussion.
Currently make check runs tests of whole EFL.Enabled running
of tests of individual modules by make check-<modulename>
Signed-off-by: kabeer khan <kabeer.khan@samsung.com>
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary: null.eo was missing in the makefile.
Test Plan: run make distcheck
Reviewers: q66
Reviewed By: q66
Subscribers: cedric, herdsman
Differential Revision: https://phab.enlightenment.org/D1999
Local and base class functions are supported.
When @empty is provided, dummy functions (initializing the parameters with default
values if needed) are generated.
When @auto is provided on properties, access to internal data variables is done. On
set, it will assign parameters values to private data members. On get,
parameters are set with private data members values.
See the supplied tests as examples.
@feature
This is needed when get properties or methods have to return a
value in case of failure or to initialize parameters.
The way used is to generate an intermediate function that will
initialize the parameters and then invoke the "user" function.