On Wed, 26 Oct 2011 12:37:12 +0200 (CEST) Vincent Torri <vto...@univ-evry.fr> said:
> > > 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. it's like that because no efl headers ever BEFORE relied on the "hosts" config.h - in fact they NEVER EVER EVER should do thbis. the header from a lib should provide the same features always -r egardless of what is in the apps config.h. sure - the app CAN try and disable features by playing with #define and #undef games but it should not accidentally happen - ie all #ifdefs should be namespaced OR be compiler or architecture or platform specific. relying in #define __GNU_SOURCE or other friends to be defined by the app is bad. > 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). that's a REAL pain in the arse as then the top of every file has the same set of 2, 5, 10, 20 header includes. it's maintenance hell. i put them all into the same common/private header and even if not all are used in each file, it provides a global scope for the app/lib/project that you don't have to keep re-figuring-out per file. you use eet* in file a then later need it in file b but find Eet.h isn't included so u have to go fix it again when it can just be a common include. > And I still think that it is a bug. > > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
