On Jun 17, 2014, at 4:09 AM, Илья Михальцов <morph...@gmail.com> wrote:
> This patch fixes gcc build problems on the latest OS X 10.10 SDK beta (see
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407)
fix include hack to add:
> +#ifndef __has_feature
> +#define __has_feature(x) 0
> +#endif
So, I’d like to bring this up in the larger context of autoconf, portable code
what style we’d like for people to write code in.
From a darwin .h file in /usr/include:
#if defined(__has_feature) && defined(__has_attribute)
#if __has_attribute(deprecated)
#define DEPRECATED_ATTRIBUTE __attribute__((deprecated))
#if __has_feature(attribute_deprecated_with_message)
#define DEPRECATED_MSG_ATTRIBUTE(s) __attribute__((deprecated(s)))
#else
#define DEPRECATED_MSG_ATTRIBUTE(s) __attribute__((deprecated))
#endif
#else
#define DEPRECATED_ATTRIBUTE
#define DEPRECATED_MSG_ATTRIBUTE(s)
#endif
#elif defined(__GNUC__) && ((__GNUC__ >= 4) || ((__GNUC__ == 3) &&
(__GNUC_MINOR__ >= 1)))
#define DEPRECATED_ATTRIBUTE __attribute__((deprecated))
#if (__GNUC__ >= 5) || ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 5))
#define DEPRECATED_MSG_ATTRIBUTE(s) __attribute__((deprecated(s)))
#else
#define DEPRECATED_MSG_ATTRIBUTE(s) __attribute__((deprecated))
#endif
#else
I think this serves as a great introduction to the feature and what it is, why
it exists and what it attempts to do. In short, give code writers an ability
to smell a port via #if and or if (), and write portable code without using
autoconf. Yes, for some truly hard problems, this scheme breaks down, but if
gcc and other vendor compilers follow the scheme and define these as
appropriate, then users can make use of this scheme instead of autoconf. It
was code like #if defined(__GNUC__) that causes clang to lie and say it is
gnuc, it does this, as the code doesn’t use a fine grained check for the
feature, but rather a course grained check on __GNUC__ which is wrong, as other
compilers implement __attribute__ and __attribute__((deprecated)) that are not
gcc.
http://clang.llvm.org/docs/LanguageExtensions.html has the names for the things
that clang defines. In gcc, we could elect to use the same names and define
them as appropriate for gcc. I think if gcc did this, then the quoted fix
isn’t necessary. Also, if gcc doesn’t want to do this, it is reasonable for
the darwin port to so define features, they tend to be large scale and slow
moving and monotonic in nature, so the maintenance of them should be low in
general.
What do people think?
