On Tue, 1 Nov 2011, Carsten Haitzler (The Rasterman) wrote:
> 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. 1) It's a matter of taste : I find cleaner to include only the needed header files. 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 ? :-) 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) 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. ------------------------------------------------------------------------------ RSA® Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
