okay, on IRC people clarified it with an example: Failing = http://codepad.org/qet7AgoX
Which I'd propose the solution = http://codepad.org/LVaUAJSI I was also told that eolian_cxx is only outputting header files. Although we do that, we should still output forward declarations first, then the actual methods. It would be nice if we isolate these with guards, so our deps result in correct results: $ cat a.eo.cxx #ifndef B_EO_CXX_NO_BODIES #define B_EO_CXX_NO_BODIES 1 #include "b.eo.cxx" #undef B_EO_CXX_NO_BODIES #else #include "b.eo.cxx" #endif #ifndef A_EO_CXX_DECLS #define A_EO_CXX_DECLS 1 class A { B method(); }; #endif #ifndef A_EO_CXX_NO_BODIES #ifndef A_EO_CXX_BODIES #define A_EO_CXX_BODIES 1 B A::method() { return B(); } #endif #endif $ cat b.eo.cxx #ifndef A_EO_CXX_NO_BODIES #define A_EO_CXX_NO_BODIES 1 #include "a.eo.cxx" #undef A_EO_CXX_NO_BODIES #else #include "a.eo.cxx" #endif #ifndef B_EO_CXX_DECLS #define B_EO_CXX_DECLS 1 class B { A method(); }; #endif #ifndef B_EO_CXX_NO_BODIES #ifndef B_EO_CXX_BODIES #define B_EO_CXX_BODIES 1 A B::method() { return A(); } #endif #endif Which would result in a final file such as: $ cat final.cxx #include "a.eo.cxx" #include "b.eo.cxx" $ cpp final.cxx // from #include "a.eo.cxx" in final.cxx class A { B method(); }; // from #include "b.eo.cxx" with B_EO_CXX_BODIES=1 in "a.eo.cxx" class B { A method(); }; // from #include "a.eo.cxx" in final.cxx B A::method() { return B(); } // from #include "b.eo.cxx" in final.cxx A B::method() { return A(); } On Mon, Dec 12, 2016 at 4:08 PM, Gustavo Sverzut Barbieri <barbi...@gmail.com> wrote: > it's simple, do #ifndef ... #define ... #endif, but automatically. > > That is, if: > > $ cat a.eo: > import b; > > $ cat b.eo: > import a; > > this should work, parsing b would include a, then it would include b > but that's in the hash/db already and then NOOP. > > Also, it's even more annoying for documentation... In Efl.Net.Dialer > I'd like to point out that it's the base class and users should look > into @Efl.Net.Dialer.Simple... but in that case I'd not even like to > import such file, it should be auto-discovered. > > > > > On Mon, Dec 12, 2016 at 3:15 PM, Felipe Magno de Almeida > <felipe.m.alme...@gmail.com> wrote: >> On Mon, Dec 12, 2016 at 3:10 PM, <marcel-hollerb...@t-online.de> wrote: >>> Ping? Anyone? >> >> I agree with you. I have no idea on how to fix it, however. >> >> Regards, >> >>> On Fri, Nov 18, 2016 at 04:18:00PM +0100, marcel-hollerb...@t-online.de >>> wrote: >>>> Hello, >>>> >>>> i would like to get back to this. >>>> >>>> On Tue, Nov 01, 2016 at 11:48:50AM -0700, Jee-Yong Um wrote: >>>> > cedric pushed a commit to branch master. >>>> > >>>> > http://git.enlightenment.org/core/efl.git/commit/?id=0fd144550877ff0a6f413c025685b7e7d63e6535 >>>> > >>>> > commit 0fd144550877ff0a6f413c025685b7e7d63e6535 >>>> > Author: Jee-Yong Um <con...@gmail.com> >>>> > Date: Tue Nov 1 10:59:09 2016 -0700 >>>> > >>>> > edje.object: implement Efl.Observer interface >>>> > >>>> > Summary: >>>> > To remove duplicated lines to handle edje class (color, text, size), >>>> > observer interface is implemented to Edje.Object. >>>> > >>>> > Reviewers: jpeg, cedric >>>> > >>>> > Reviewed By: cedric >>>> > >>>> > Subscribers: bu5hm4n, cedric >>>> > >>>> > Differential Revision: https://phab.enlightenment.org/D4359 >>>> > >>>> > Signed-off-by: Cedric BAIL <ced...@osg.samsung.com> >>>> > --- >>>> > src/Makefile_Efl.am | 3 + >>>> > src/lib/edje/edje_load.c | 8 +- >>>> > src/lib/edje/edje_main.c | 45 +++- >>>> > src/lib/edje/edje_object.eo | 4 +- >>>> > src/lib/edje/edje_private.h | 19 +- >>>> > src/lib/edje/edje_smart.c | 50 ++++ >>>> > src/lib/edje/edje_text.c | 8 +- >>>> > src/lib/edje/edje_textblock_styles.c | 6 +- >>>> > src/lib/edje/edje_util.c | 441 >>>> > ++++--------------------------- >>>> > src/lib/efl/Efl.h | 3 + >>>> > src/lib/efl/interfaces/efl_observable.eo | 63 +++++ >>>> > src/lib/efl/interfaces/efl_observer.c | 259 ++++++++++++++++++ >>>> > src/lib/efl/interfaces/efl_observer.eo | 15 ++ >>>> > src/lib/efl/interfaces/efl_types.eot | 6 + >>>> > 14 files changed, 514 insertions(+), 416 deletions(-) >>>> > >>>> [snip] >>>> > +#include "efl_observable.eo.c" >>>> > +#include "efl_observer.eo.c" >>>> > diff --git a/src/lib/efl/interfaces/efl_observer.eo >>>> > b/src/lib/efl/interfaces/efl_observer.eo >>>> > new file mode 100644 >>>> > index 0000000..a0d4ffe >>>> > --- /dev/null >>>> > +++ b/src/lib/efl/interfaces/efl_observer.eo >>>> > @@ -0,0 +1,15 @@ >>>> > +interface Efl.Observer { >>>> > + methods { >>>> > + update @virtual_pure { >>>> > + [[Update observer according to the changes of observable >>>> > object. >>>> > + >>>> > + @since 1.19]] >>>> > + params { >>>> > + /* FIXME: obs should be Efl.Observable, but cyclic >>>> > dependency error occurs. */ >>>> > + @in obs: Efl.Object; [[An observable object]] >>>> >>>> It looks like this is never going to change. So i guess its quite >>>> dangerous to leave this interface like this, since its not going to work >>>> like this. And the interface itself probebly needs to be defined in a >>>> way that it works with the way eolian handles cyclic dependencies >>>> >>>> Greetings >>>> Marcel Hollerbach >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> enlightenment-devel mailing list >>>> enlightenment-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >>> >>> ------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> enlightenment-devel mailing list >>> enlightenment-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> >> >> >> -- >> Felipe Magno de Almeida >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> _______________________________________________ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > -- > Gustavo Sverzut Barbieri > -------------------------------------- > Mobile: +55 (16) 99354-9890 -- Gustavo Sverzut Barbieri -------------------------------------- Mobile: +55 (16) 99354-9890 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
