Re: [E-devel] problem with Eina and pthread.h (to fix before 1.1 release)

[Jorge L. Z. M. <jor...@gm...>]

On Wed, Oct 26, 2011 at 12:37 PM, Vincent Torri <vt...@un...> wrote:
>
>
> On Wed, 26 Oct 2011, Cedric BAIL wrote:
>
>> On Wed, Oct 26, 2011 at 11:10 AM, Vincent Torri <vt...@un...> wrote:
>>> On Wed, 26 Oct 2011, Cedric BAIL wrote:
>>>> On Wed, Oct 26, 2011 at 10:55 AM, Vincent Torri <vt...@un...> 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
>> enl...@li...
>> 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
> enl...@li...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>