> 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. Ok no problems then. I already started to do this job on the engines. I will do the necessary modifications on the lib (that is already done with my convention unfortunately, but a sed will help me a lot). > Yes, doing that for all the modules is quite long (and boring...) Speaking of modules and engines. I am not sure that I fully understand the way the modules (engines) are loaded. What is the first (and last) function called after the loading. Is it module_open (module_close before unloading) or is it eng_setup. was not able to find any explicit info in the code and the number of macros used everywhere did not help me much either :-(. This is important since we have to define the log domain early so if I understand the code it should be defined in the module_open function.
I try to finish as soon as possible. best Mathieu ------------------------------------------------------------------------------ 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
