In fact EXALT_LOG_DOMAIN is private. The others projects have to define it if they want use the macros EXALT_ASSERT_*, else gcc will returns an error (undefined EXALT_LOG_DOMAIN).
2009/9/2 Gustavo Sverzut Barbieri <barbi...@profusion.mobi> > On Wed, Sep 2, 2009 at 5:06 AM, Atton Jonathan<jonathan.at...@gmail.com> > wrote: > > This is not internal. I have one low level library which define a list of > > macro for doing assertion. (EXALT_ASSERT_*). These macros use > EXALT_LOG_*. > > The daemon and the dbus library use these assertions, that's why > EXALT_LOG > > is not internal. > > but is this lib used by other projects? (ie: e module?) IF so, then > even define EXALT_LOG_ prefix is bad, it should be private to your > lib/app. You want your emodule to have its own domain and not log in > behalf of exalt. > > If you are concerned about lib and app using the same macros, then > create a private header that is shared by both. > > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: barbi...@gmail.com > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > -- Regards. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
