Summary: | imake is failing with clang | ||
---|---|---|---|
Product: | xorg | Reporter: | Sylvestre Ledru <sylvestre> |
Component: | Build/Monolithic | Assignee: | Jeremy Huddleston Sequoia <jeremyhu> |
Status: | RESOLVED MOVED | QA Contact: | Xorg Project Team <xorg-team> |
Severity: | minor | ||
Priority: | low | CC: | jeremyhu, niederstrasser |
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | 2012BRB_Reviewed | ||
i915 platform: | i915 features: |
Description
Sylvestre Ledru
2012-02-01 10:47:42 UTC
What do you need imake for? From https://trac.macports.org/ticket/31504 "This is because clang cannot interpret Concat3() macro properly which is declared in Imake.rules." I'm looking into it as well. Don't think I'm blowing you off based on the comment above ;) gcc doesn't like it either, so this doesn't seem like a clang issue: ~ $ cat test.c #if (defined(__STDC__) && !defined(UnixCpp)) || defined(AnsiCpp) #define Concat3(a,b,c)a##b##c #else #define Concat3(a,b,c)a/**/b/**/c #endif #define ProjectRulesFile Concat3(<,TopLevelProject,.rules>) ProjectRulesFile ~ $ /usr/bin/gcc -E test.c # 1 "test.c" # 1 "<built-in>" # 1 "<command-line>" # 1 "test.c" # 9 "test.c" test.c:9:1: error: pasting "<" and "TopLevelProject" does not give a valid preprocessing token test.c:9:1: error: pasting "TopLevelProject" and "." does not give a valid preprocessing token <TopLevelProject.rules> I am using imake to build some debian packages with clang. Thanks for digging that quickly. FWIW, you can use IMAKECPP to work around this for now: IMAKECPP=/usr/bin/cpp xmkmf IMAKECPP=/usr/bin/cpp make Makefiles or /usr/lib/cpp or whatever... setting it to "cc -E" doesn't work though. Since it's not a clang regression over gcc at the macro level, my guess is clang is somehow going down a different cpp path than gcc. The different path taken in comment 3 is due to not using -traditional like imake does. Using this option causes __STDC__ to be undefined. In gcc it appears that -traditional implies -traditional-cpp, but clang does not support -traditional-cpp at all. So the actual bug here is that these macros need traditional preprocessor behaviour (which apparently includes removing comments without inserting any whitespace, and ignoring empty character constants) to expand correctly, and clang does not provide that. Actually, it looks like newer clang versions do accept -traditional-cpp, but apparently they still don't emulate the traditional behaviour closely enough for this code to work. Mike from Homebrew here. Thought the patch in this pull request may be useful to you: https://github.com/samueljohn/homebrew/commit/398110#L0R35 More discussion here: https://github.com/mxcl/homebrew/pull/16420 Thanks, but unless I'm missing something, the patch in https://github.com/samueljohn/homebrew/commit/398110#L0R35 has nothing to do with what's in our imake git repo - we have no file named imake.rb, and our configure script is autogenerated by the GNU autoconf tool and not checked into git, nor manually edited. Hi, I am using imake to build a project and am affected by the bug. I understand the workaround using the environment variable IMAKECPP to make imake use a different pre-processor, but with the combination of OSX mavericks and xcode 5, there is only one cpp on the system, clang. -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/util/imake/issues/1. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.