A concrete example of the previous email is the following files:

a.eo.cxx: http://codepad.org/BzCSLMk7
b.eo.cxx: http://codepad.org/yD60mWmy
final.cxx: http://codepad.org/rZfvzIHe

$ cpp -x c++ final.cxx # http://codepad.org/VqTZe6FJ

# 1 "/tmp/final.cxx"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "<command-line>" 2
# 1 "/tmp/final.cxx"
# 1 "/tmp/a.eo.cxx" 1
# 1 "/tmp/b.eo.cxx" 1
# 1 "/tmp/a.eo.cxx" 1
# 21 "/tmp/a.eo.cxx"
class B;

class A {
public:
   B method();
};
# 9 "/tmp/b.eo.cxx" 2
# 21 "/tmp/b.eo.cxx"
class A;

class B {
public:
   A method();
};
# 9 "/tmp/a.eo.cxx" 2
# 34 "/tmp/a.eo.cxx"
# 1 "/usr/include/c++/6.2.1/iostream" 1 3
# 36 "/usr/include/c++/6.2.1/iostream" 3

// removed lots of iostream include stuff...

# 35 "/tmp/a.eo.cxx" 2

# 35 "/tmp/a.eo.cxx"
B A::method() {
   std::cout << "A::method() will return B()" << std::endl;
   return B();
}
# 2 "/tmp/final.cxx" 2
# 1 "/tmp/b.eo.cxx" 1
# 35 "/tmp/b.eo.cxx"
A B::method() {
   std::cout << "B::method() will return A()" << std::endl;
   return A();
}
# 3 "/tmp/final.cxx" 2

int main() {
  B b = A().method();
  A a = B().method();
  return 0;
}







On Mon, Dec 12, 2016 at 4:50 PM, Gustavo Sverzut Barbieri
<[email protected]> wrote:
> 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
> <[email protected]> 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
>> <[email protected]> wrote:
>>> On Mon, Dec 12, 2016 at 3:10 PM,  <[email protected]> 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, [email protected] 
>>>> 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 <[email protected]>
>>>>> > 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 <[email protected]>
>>>>> > ---
>>>>> >  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
>>>>> [email protected]
>>>>> 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
>>>> [email protected]
>>>> 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
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
>>
>>
>> --
>> Gustavo Sverzut Barbieri
>> --------------------------------------
>> Mobile: +55 (16) 99354-9890
>
>
>
> --
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to