(updated a couple days later... Figured out the problem, but noting that at the end... otherwise: a couple typos fixed)

commonCode has run on well-over a half-dozen different versions of GCC... Apple's from 10.5.8, several different versions of avr-gcc, now gcc on linux... spanning gcc's from 4.0.something (was it 3.something?) through 4.7.2...

but xc32-gcc/cpp seems to be mangling it quite royally. (See the fix at the end)

makefile:

COMDIR = ../../../_commonCode

VER_BITHANDLING = 0.95
BITHANDLING_HDR = $(COMDIR)/bithandling/$(VER_BITHANDLING)/

CFLAGS += -D'_BITHANDLING_HEADER_="$(BITHANDLING_HDR)/bithandling.h"'

the end-result (when running gcc with -E -dM) should be:

#define _BITHANDLING_HEADER_ "../../../_commonCode/bithandling/0.95/bithandling.h"

(yes, in quotes)

Then main.c uses:

#include _BITHANDLING_HEADER_

Yeah, it's a little ugly on the makefile side, but there's reason for it.

There's a name for it: "Computed Includes" and there's a whole section in 'info cpp', including mention of using the command-line option -D to do-so...

And, a significant portion of #commonCode (not exclusively for AVRs) relies on this technique, and has for several years.

Instead, with xc32-gcc (Microchip's toolchain) what I get is:

#define _BITHANDLING_HEADER_ ../../../_commonCode/bithandling/0.95

1) No quotes (where'd they go? BASH didn't mangle 'em, I can compile this on avr-gcc and linux's gcc on the same system, same 'bash', same 'make' without trouble).

2) It completely dropped everything after $(BITHANDLING_HDR) (/bithandling.h"')

No complaints about missing endquotes...

And a few more hacks resulted in even weirder stuff... Including Macros whose closing-parentheses were apparently never reached, and never complained about.. Like this:

CFLAGS += -D'_QUOTETHIS_( x)=\#x'
CFLAGS += -D"_BITHANDLING_HEADER_=_QUOTETHIS_($(BITHANDLING_HDR)/bithandling.h)"

which results in:

../../../_commonCode/heartbeat/2.05/heartbeat.h:319:11: error: unterminated argument list invoking macro "_QUOTETHIS_"
#include _BITHANDLING_HEADER_
^

which doesn't make an ounce of sense, clearly it's terminated, Even tried ' instead of " and various others...

And, even weirder, the output results in:

#define _BITHANDLING_HEADER_ _QUOTETHIS_(../../../_commonCode/bithandling/0.95
#define _QUOTETHIS_(x) #x

... and it seems to be cut-off at the same place... immediately after the *makefile* variable... which shouldn't even appear to any of the xc32 utilities... and is, in fact, the same make used by the other gcc-toolchains that work fine.

Maybe it's because of this crippled ("free license") version, but that's some REALLY WEIRD SHIZZLE.

...right?

--------------

Update a couple days later:

Turns out: xc32-gcc is removing the quotes, *all of them* wherever they lay in the command-line. No, it's not bash's doing, no it's not make's doing... the compiler shouldn't be doing this, right? Maybe it has something to do with its being aimed at Windows rather'n linux?

Anyhow:

The Fix is explained here at stack-overflow, as that's also where I figured out the problem. The end-result is a necessity to:

1) remove ' and replace " with \"

2) replace \" with \\\"

That first bit's just for an alleged portability-increase for the original -D'...="..."' method to -D...=\"...\"

That should be effectively the same as the original in all cases, while also plausibly being compatible with other operating-systems I haven't tried.

The next bit is the oddity of xc32-gcc... apparently the quotes need to be escaped *again* dispite already being escaped...

thus the regular escaped-quote that bash passes into xc32-gcc: \" is removed, unless it's *escaped again* with \\\"

Again, oddly, this isn't a bash-thing, this is definitely an xc32-gcc thing. Weird.

So, now commonCode tests which compiler you're using and extra-escapes if necessary. (ultimately, maybe, there might be a more automatic way of detecting whether this is necessary, regardless of the CC used... TODO)