On Tue, Jun 23, 2009 at 08:16:27AM +0200, Gabriel Kerneis
<[email protected]> wrote:
> > Sounds more like a bug in the code of those users to me (_GNU_SOURCE
> > is a reserved macro name, and ev.h can be included regardless of how
> > _GNU_SOURCE is defined).
>
> _GNU_SOURCE has to be defined *before* the inclusion of any other
> header,
Not really, just before system headers (_GNU_SOURCE is a bad example, of
course, as you won't really find the definite reference for this symbol
anywhere, but let's assume it works like _POSIX_SOURCE).
> and ev.h is included automatically with cpc_runtime.h at the very
> begining of cpc files, so *before* anything the user might define.
That's of course a shortcoming of cpc - if cpc wants to provide the user
with full access to posix/gnu extensions etc. then it needs to provide a
way to define those symbols.
> the information is not carried in the source code anymore. Anyway, I
> agree this is not quite a bug in libev, and being able to work-around it
> via macro definitions is fine to me. I was just curious about the
> sig_atomic_t != int stuff.
Yeah, what you do with it is up to you (as long as the license is followed
:). Taking advantage of the "cleanliness" of ev.h is not morally bad in
any way (and it was of course written with "as little include files as
required" in mind).
Note, however, that you are not free to define just about anything. Most
GNUL/Linux distros, for example, default to 32 bit interfaces by default
(unlike virtually any other system, which only offers 32 bit interfaces
for compatibility).
This means that precompiled libev packages will of course be compiled with
whatever is the default abi, so you will get a 32 bit stat structure.
Askign fro the lfs abi will break the header.
So in general, you cannot compile the header file with substantially
different flags than the implementation file.
If you want to support that, it's manual hackwork anyways (which is,
again, morally acceptable :)
(I have not found a satisfactory solution to the struct stat issue so far,
and I think I looked very hard)
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [email protected]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
