On Tue, 1 Nov 2011 01:23:01 +0100 (CET) Vincent Torri <[email protected]> said:
> On Tue, 1 Nov 2011, Carsten Haitzler (The Rasterman) wrote: > > > On Wed, 26 Oct 2011 12:37:12 +0200 (CEST) Vincent Torri > > <[email protected]> said: > > > >> > >> > >> On Wed, 26 Oct 2011, Cedric BAIL wrote: > >> > >>> On Wed, Oct 26, 2011 at 11:10 AM, Vincent Torri <[email protected]> > >>> wrote: > >>>> On Wed, 26 Oct 2011, Cedric BAIL wrote: > >>>>> On Wed, Oct 26, 2011 at 10:55 AM, Vincent Torri <[email protected]> > >>>>> 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. > > 1) It's a matter of taste : I find cleaner to include only the needed > header files. true. i prefer my c files with less stuff at the top. :) > 2) it's not a maintainance hell : I did it once, for several libs. As they > are stable, *no* maintainance is needed. So i don't see why it is a pain, > nor for you (who do not touch them anyway), or for me (who maintain anyway > those includes). So everyone is happy. Can you really think that I find > that bothering, me, the current autotools and Windows port maintainer ? > :-) well it's painful during development... i've had to add headers a few times before because of this as i expected to be able to use the same apis in one part of a lib as another. > 3) with that method, one of the problem of Eina i raised (I insist :-) ) > would have been solved without including config.h before your *_private.h > of each source file using features allowed by, e.g. _GNU_SOURCE (like > CPU_SET) yeah - it would solve it, but its a bi-product - an inadvertent "fix" that was not intended. if Eina.h RELIES on the app including config.h and defining __GNU_SOURCE to work then that's wrong. if anything it probably should do something like: #ifndef __GNU_SOURCE #define NO_GNU_SOURCE #define __GNU_SOURCE 1 ...(rest of eina header here) #ifdef NO_GNU_SOURCE #undef NO_GNU_SOURCE #undef __GNU_SOURCE #endif at least then the eina features would be isolated from the app itself (if eina really needs/wants __GNU_SOURCE set) > Vincent > > > 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. > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ RSA® Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
