On Fri, Dec 09, 2011 at 08:43:44AM +0100, Hongli Lai <hon...@phusion.nl> wrote:
> Here's a new patch should be less invasive than the last one. The new
> approach is as follows:
> - Introduced an ECB_REAL_GCC macro which tells us whether the GCC is
> the real one or another implementation just claiming to be GCC.
> llvm-gcc is not considered to be real.
> - Introduced an ECB_APPLE_LLVM_GCC macro which tells us whether this
> is Apple's llvm-gcc as shipped with OS X.
> - Introduced an ECB_ADVERTISED_GCC_VERSION macro which is like
> ECB_GCC_VERSION, but does not blacklist non-real GCC compilers.

That is very complicated.

> - Various features such as __inline__ and __attribute__ support are
> explicitly whitelisted, e.g. like this: ECB_APPLE_LLVM_GCC &&
> ECB_ADVERTISED_GCC_VERSION(3,1)

But we have no indication that apple's llvm (or even the official llvm-gcc
version it is based on) actually does support attribute just like gcc. In
fact, I am pretty sure it doesn't.

Please note that this isn't just about features libecb uses, but also
features that users of libecb use, which libecb has no control over.

So announcing the availability of gcc's attribute when it's not actually
true might work with libebc itself, but not with user code.

So, here are I think the killer arguments (sumarised from my previous
reply):

- apple's llvm-gcc is long obsolete
- it does create correct code
- it can be configured not to emit any warnings, with improved performance,
  by switching to c99 mode.

So your entire complex patch exists not to improve anything of substance
(such as making code work on apples llvm), just to silence a few compiler
warnings. I think it's just not worth it for a compiler that has long
since been replaced.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schm...@schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\

_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev

Reply via email to