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.