Re: [E-devel] E SVN: seoz IN trunk/ecore: doc src/lib/ecore

[Daniel J. S. <seo...@gm...>]

>>  I personally dislike the fact that our
>> header are growing that much and much prefer eina's header, where each
>> of the functionnality have it's own header

I already raised the same suggestion but raster disliked header separation.
http://www.mail-archive.com/enl...@li.../msg32229.html
We had no agreement at that time.

Daniel Juyung Seo (SeoZ)


On Tue, May 24, 2011 at 9:39 PM, Cedric BAIL <ced...@fr...> wrote:
> On Tue, May 24, 2011 at 1:59 PM, Vincent Torri <vt...@un...> wrote:
>> On Tue, 24 May 2011, Daniel Juyung Seo wrote:
>>> It's already done in other libs such as evas, edje, eina, ...
>>>
>>> And ecore has missing documentations on the website due to this.
>>> http://docs.enlightenment.org/auto/ecore/
>>> Compare this with Evas documentation.
>>> http://docs.enlightenment.org/auto/evas/
>>
>> i would like to do the contrary for all the libraries : having a .dox file
>> in doc/. One of the reason is to update the version number automatically
>> with configure. See line 13 of the current Ecore.h. The other solution would
>> be to have an Ecore.h modified by configure, and I don't like this.
>>
>> The other reason is to not pollute the main header with such doc and to
>> actually give a documentation of all the components of an EFL in a single or
>> several dox files
>
> I don't know much about your plan, idea, but one of the good point of
> moving doc to header, is that we could generate doc with just the
> header (so any distribution that provide a dev package, can be the
> source of a local doxygen doc). I personally dislike the fact that our
> header are growing that much and much prefer eina's header, where each
> of the functionnality have it's own header... But that's another
> discussion, so just forget my last grumbl :-)
> --
> Cedric BAIL
>