On Wed, Oct 26, 2011 at 12:37 PM, Vincent Torri <vto...@univ-evry.fr> wrote: > > > On Wed, 26 Oct 2011, Cedric BAIL wrote: > >> 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, > > hell, just look at raster's use of headers : he puts everything in a > _private.h (config.h too). If he wants to use Eina: > > #include Eina.h > > #include "exported_header.h" > #include "***_private.h" > > and boum, it will fail with Eina if he wants to use CPU_SET. He will have > to include config.h before Eina.h in a specific source file, while it's > alreay included in his _private.h. > > Don't tell me how to use these headers. In case you don't remember, it's > ME who moved all the inclusion of the headers from the *_private.h to the > source file, to avoid such problems (especially on Windows where it's even > more evil). > > And I still think that it is a bug.
Hi all, I agree with Vincent, but beside the header order issue of how should we put our own headers (libraries or apps that use eina) to make eina happy, there's a more critical problem. The main issue here is that a compiler flag that in theory is for our own library/app only might modify eina's behaviour and the other way around, that's no sense and must not happen in any circumstance. Regards > > Vincent > >> 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 >> >> > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
