On Wed, Oct 26, 2011 at 11:10 AM, Vincent Torri <vto...@univ-evry.fr> wrote: > On Wed, 26 Oct 2011, Cedric BAIL wrote: >> On Wed, Oct 26, 2011 at 10:55 AM, Vincent Torri <vto...@univ-evry.fr> wrote: >>> Eina includes eina_inline_lock_posix.h on something else than Windows, >>> hence pthread.h. _GNU_SOURCE is not defined. >>> >>> Suppose now that a user of Eina does this: >>> >>> #include <Eina.h> >>> #include <pthread.h> >>> >>> The user will not have the possibility to features available with >>> _GNU_SOURCE (like CPU_SET for example. I have that problem with Enesim), >>> except by defining it just before including Eina.h. Which is not the best >>> solution, I think. >>> >>> The problem, here, is that lock stuff is only inlined functions. The >>> problem will be solved if they are in a source file. Maybe at the >>> beginning, having these functions inlined was interesting because they >>> were short. I'm not sure that keeping them inlined is really useful, now. >> >> As from a performance point of view, it really matter to have them >> inlined or not. Function call does cost. >> >>> Another solution would be to define _GNU_SOURCE before including pthread.h >>> (maybe under some conditions). But is it a good solution too ? >>> >>> Honestly, I don't know what the best solution is. So if someone knows how >>> to properly fix that problem... >> >> I have always started to put libc header first if I need them directly >> and then include other library. This just solve this kind of issue. So >> I don't thing it's an issue to solve. > > well, if you think that everyone on earth must code like you...
Actually, what would you say to someone that put #ifdef HAVE_CONFIG_H at the end of the C file. That's bad idea and that's the same here. It's just sane to put config first, then include C library and then all headers in their dependencies order. Because there is some inline/define value in the libc and in any header that could directly affect any header/library that use it, meaning any C library. It is a dependence of it and it make sense to just respect dependencies order to avoid any issue. > For me it is a bug. If you don't want to change anything, then documentation > must describe that, and in addition, adding a #warning in eina_inline_posix.x > if _GNU_SOURCE is not defined would be useful too. If you want. -- Cedric BAIL ------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
