Hi Raster,
I know it is a long time we didn't speak about that but I would like to
reopen it to decide the interaction between files.
As I explained before, we have at least two files by class:
- the eolian-generated file that contains all the legacy/Eo functions
- the "user" file that contains the logic part of the functions. There
can be more than one file of this type
The question is: who is supposed to include who?
- you suggested that the auto-generated file will include the user
files. That can be done by replacing in the makefile these files by the
new one and by giving to Eolian command line the different files to include
- we suggested (more began like that) that one "user" file will include
the auto-generated. We let the makefile as is but we must add into the
auto-generated file externs to the user functions that will no more be
static.
I think yours is cleaner but I would like to be sure it is ok (i.e we
thought about all the consequences) before beginning changing the generator.
Thank you, boss
JackDanielZ, alias Daniel the 3rd.
On 01/01/2014 02:18 PM, daniel.za...@samsung.com wrote:
> On 12/31/2013 10:03 AM, Carsten Haitzler (The Rasterman) wrote:
>> On Thu, 12 Dec 2013 16:14:34 +0200 "daniel.za...@samsung.com"
>> <daniel.za...@samsung.com> said:
>>
>>> Hi all,
>>>
>>> As you maybe know, we are developing a tool (Eolian) that will help
>>> people to add functions to the Eo classes and to generate automatically
>>> bindings. We spoke a lot about the .eo format to describe the classes
>>> but we never spoke about the generator. So is the time.
>>>
>>> The solution chosen to generate C code is to have two files:
>>> - the first one is fully auto-generated by Eolian and contains EAPI
>>> legacy functions and Eo code
>>> EAPI Eo_Op... = EO_NOOP;
>>> ...
>>> EAPI void
>>> evas_object_image_mmap_set(Evas_Object *eo_obj, const Eina_File *f,
>>> const char *key)
>>> {
>>> eo_do(eo_obj, evas_obj_image_mmap_set(f, key));
>>> }
>>>
>>> static void
>>> _eo_evas_object_image_mmap_set(Eo *eo_obj, void *_pd, va_list *list)
>>> {
>>> const Eina_File *f = va_arg(*list, const Eina_File *);
>>> const char *key = va_arg(*list, const char*);
>>> _mmap_set(obj, f, key); *// User function located in the second C
>>> file*
>>> }
>>> ...
>>> static void
>>> _class_constructor(Eo_Class *klass)
>>> {
>>> const Eo_Op_Func_Description func_desc[] = {
>>> EO_OP_FUNC(EO_BASE_ID(EO_BASE_SUB_ID_CONSTRUCTOR), _constructor),
>>> EO_OP_FUNC(EVAS_OBJ_IMAGE_ID(EVAS_OBJ_IMAGE_SUB_ID_MMAP_SET),
>>> _eo_evas_object_image_mmap_set),
>>> ...
>>> }
>>> ...
>>>
>>> - the second file contains the user code. It is not touched by Eolian.
>> so the "user" edits the generated file above to fill in
>> _eo_evas_object_image_mmap_set() for example (eolian generates that function
>> stub with just enough boilerplate to get them going) right? so it doesnt
>> fully
>> generate but it also has to update/edit/merge in changes from the eo file.
>> this
>> generated file #includes the totally "custom user code never touched by
>> eolian"
>> right? or this eo generated file is NEVER edited by the user and the user has
>> to write the _mmap_set() func by hand? or does eolian generate these empty
>> stubs for the user (or update them if params change)? it'd be nice if it
>> could
>> generate them when they get added to the class with an empty function the
>> "user" then has to fill. which one is it? i would definitely vote for eolian
>> generating at least empty stub functions so things compile (and likely dont
>> work or do anything useful).
> The "user" edits its own file and implements the functions that are
> expected by the generated file.
> Creating stub functions implies that we need to parse C code and that's
> what we want to prevent.
> If you want to create stubs, you have to know a destination file. For
> most of the cases, it is easy because all the functions of the class are
> defined in a same file. But we have classes (Evas Object, Edje iirc...)
> whose user functions are splitted into many files. It would mean you
> have to indicate which function you want to create in a certain file.
> Imo, it is preferable that things don't compile so that you will not
> forget to implement it.
>> for the func name - static so they dont leak out, ensure the "user" file is
>> #included into the eolian generated file so we keep all symbols local and i'd
>> say start with _ and add _eoimpl_ (eo implementation) just to ensure it wont
>> clash with anything else.
>>
>> static void
>> _eoimpl_mmap_set(Eo *obj, Eina_File *f, const char *key)
>> {
>> }
> For the moment, the "user" file includes the generated file. In this
> way, we don't change the makefiles (I know, bad reason).
> If we do as you suggested, we have to include many files in the case of
> scattered functions and put the generated files into the makefiles. The
> issue here is how we can know which files have to be included. Maybe as
> parameter of Eolian.
> With our solution, only one "user" file includes the generated file but
> we will have to set the user functions as extern into the generated file
> and to remove the static and that's bad. Except if the main "user" file
> of the class (e.g evas_object_main.c) includes the other "user" files of
> the class and the generated file. And so we will just have to remove
> them from the makefiles.
> The solution you suggest seems better. Well, I am your minion, so I must
> agree with you ;-). Seriously I don't know which way to choose for the
> moment.
>
> Concerning the naming conventions, we use for example
> _eo_obj_load_dpi_get into the generated file and
> _evas_image_load_dpi_get into the "user" file.
>>
>>
>>> This separation facilitates the generation for the C files. In the
>>> future, when Eo2 is operational, we will be able to switch fast by
>>> invoking Eolian to generate legacy and Eo2.
>>>
>>> I think this is the best time to speak about the changes we can make in
>>> the current code to set code conventions:
>>> - Eolian-generated Eo functions have to call user functions. Which
>>> convention for the function name? We decided for the moment to go on the
>>> operation only (_mmap_set).
>>> - Prototypes of user constructor and destructor. Since we are not
>>> supposed to see neither va_list nor parameters (except custom
>>> constructors), we chose to give only the object: static void
>>> _constructor(Eo *obj)...
>>> - Data names are for the moment not following the same style. We have
>>> Evas_Object_Image and Elm_Button_Smart_Data. Since "Smart" comes from
>>> Evas_Object_Smart inheritance, I think it can be removed. On the other
>>> way, Evas_Object_Image is imo not enough specific. We could change these
>>> names to Evas_Image_Data and Elm_Button_Data. Maybe we can change too
>>> Evas_Object_Protected_Data to Evas_Object_Data, since I don't see for
>>> the moment the utility of a possible public/protected/private data type.
>>>
>>> I hope that next week, we will show how it will look like on a simple
>>> and little example like ... evas_object_image.c ;-)
>>>
>>> JackDanielZ, alias Daniel the 3rd
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Rapidly troubleshoot problems before they affect your business. Most IT
>>> organizations don't have a clear picture of how application performance
>>> affects their revenue. With AppDynamics, you get 100% visibility into your
>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
>>> Pro!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> enlightenment-devel mailing list
>>> enlightenment-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
