On Thu, 24 Sep 2009, Mathieu Taillefumier wrote:

>
>> Hey,
>> 
>>> this patch should solve your problem on windows. I rename the ERROR, INFO, 
>>> etc to EVAS_ERROR, etc... and made the necessary changes in the code. 
>>> should point out that the compilation will fail if you use the 
>>> -fvisibility=hidden option with gcc (if you are using it) for the modules 
>>> (i think they are *.so kind of things on linux) I send a patch yesterday 
>>> for eet and efreet that corrected this bug but I had to define the macros 
>>> for every modules which cumbersome and prone to errors.
>> 
>> can you tell me the difference between ERR and ERROR. I don't see any, as, 
>> afaics, _EVAS_DEFAULT_MODULE_LOG_DOM is the same than _evas_log_dom_global
> Sure. I original idea was to give a macro name that is different for the 
> module and the main library and define the macros in a centralized way in  a 
> common file (in this case evas_common.h) instead of having then duplicated 
> everywhere.
>
> As you remarked the only difference in the macro EVAS_ERROR and EVAS_ERR is 
> that the macro EVAS_ERROR use the log domain of the main lib while EVAS_ERR 
> use the macro _EVAS_DEFAULT_MODULE_LOG_DOM which should point to the default 
> log domain used by the module. Now If the module does not have any init 
> function then the macro _EVAS_DEFAULT_MODULE_LOG_DOM can be let alone (NOT 
> REDEFINED) and the default domain will be the one defined for the main 
> library. In the second case, the module contains an init function so we 
> create a log domain and just redefine the macro _EVAS_DEFAULT_MODULE_LOG_DOM 
> with the domain name of the module. In both cases, you do not have to 
> redefine the macros and we can just use EVAS_ERR (we call it EVAS_MOD_ERR) in 
> the module without thinking about the log domain.
>
> There is drawback with this solution. Compiling the library with 
> -visibility=hidden will not work for the modules that use the log domain of 
> the main library (somehow the domain variable of the library is not 
> exported). So far the only way to treat that is to use EINA_LOG_ERR (and the 
> others routines) in the modules that do not have their personal log domain 
> for logging but we loose in granularity.
>
> I finally understood yesterday how the different engines work. There is an 
> init function in each engine so I can define an individual log domain for 
> each of them. I started to work on that but it takes somehow more time than I 
> expected. For now, all modules, engines, etc... use the log domain the evas 
> library so deactivate the -fvisibility=hidden option for now. I am working on 
> that but I did not have time to prepare a patch that is explicit.
>
> Last point, I used EVAS_ERROR (and their other equivalent) in all modules but 
> I indent to change that quickly and come back to EVAS_ERR (or more a explicit 
> name) as soon as possible. So if you want to add logging just use EVAS_ERR in 
> the module you are working on. I am sorry for this mess.

I think that we should stick to what Gustavo wants : using only 3 letters 
long macro (ERR, INF DBG, WRN) in evas and the modules. Each module will 
have it's own logging domain.

Yes, doing that for all the modules is quite long (and boring...)

regards

Vincent

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to