Done. But note that it's my wizardly co-worker, Pete Keller, who has done all the work. 
I'll see what advice I can get from him.

> As a postscript: getting FD to work with Apple's compiler would involve much
> more work.  My colleague Pete Keller has spent a bit of time on this.
> Notably, Apple's compiler does not treat a struct declaration as synonymous
> with a class declaration with everything public, although GCC accepts this.
> Also, Apple's compiler seems to want a little more information about generic
> uses.
>
> I have a partial patch with many of the structs replaced with "public class,"
> and some of the generics calls fixed (AFAICT, Apple is strictly more fussy
> about these, so the changes are compatible with GCC) but doing this got very
> wearing, so I have at least temporarily abandoned it. If you are interested
> in this code, LMK.

Hi Robert, we'd like to make some advances towards supporting clang, so if
you're still interested in this, maybe you can add yourself to the nosy list on
issue463.

OK, this might be resolved now. (Note that the latest change has been pushed
directly to the default branch, not the issue437 branch.) Please reopen if there
are still problems!

Actually, that was a bit premature -- sorry! I ran out of time for this during
ICAPS and then lost track of the state of the discussion. Will work on this
again and then comment again later.

I hope this is resolved now? If not, please feel free to reopen. (Adding a
comment will do this automatically.)

New patch is attached.  Also available from bitbucket.

OK, I will try to provide an alternative patch that meets these requirements.

Thanks, Robert! There are two things I'd like to change before merging. First, I
don't like that arbitrary values for BITWIDTH other than 32 behave identically,
since we usually try to complain if something doesn't make sense. How about:

- "32" or specifying nothing means "-m32"
- "64" means "-m64"
- "native" means no option?

Second, is there a way to avoid the large number of sequential #endifs? I'd
rather not nest control structures so deeply.

As a postscript: getting FD to work with Apple's compiler would involve much
more work.  My colleague Pete Keller has spent a bit of time on this.  Notably,
Apple's compiler does not treat a struct declaration as synonymous with a class
declaration with everything public, although GCC accepts this. Also, Apple's
compiler seems to want a little more information about generic uses.

I have a partial patch with many of the structs replaced with "public class,"
and some of the generics calls fixed (AFAICT, Apple is strictly more fussy about
these, so the changes are compatible with GCC) but doing this got very wearing,
so I have at least temporarily abandoned it. If you are interested in this code,
LMK.

I have a patch, which I will attach, and which is also available through the
issue437 branch at https://rpgoldman@bitbucket.org/rpgoldman/fast-downward

As the original issue indicates, this allows me to provide values for CXX and CC
on the command line of build_all.  Because some of my platforms don't support 32
bit development well, I also added a Make variable "BITWIDTH" that defaults to
32-bit per the FD repo, but can be set to something else (anything other than 32
turns off the -m32 switches pervasively).

For example, on my Mac, I build FD using GCC from MacPorts instead of the C++
compiler from Apple (which objects to some of the practices in FD, seemingly
because of disagreements about corner cases in the C++ standard) as follows:

./build_all BITWIDTH=64 CXX=/opt/local/bin/g++-mp-4.8
CC=/opt/local/bin/gcc-mp-4.8 LINKER=/opt/local/bin/g++-mp-4.8

I have done a cursory test on Linux to see that I am not breaking anything. I
built there in 64-bit also, so please check to make sure I haven't broken 32-bit
building.

We'd be happy to merge such a patch if it doesn't complicate the Makefiles too
much. (And unless I'm overlooking something, I don't think it would complicate
them at all.)

For the Mac, where it's easy to end up with multiple C and C++ compilers, I 
wanted to specify my own. This is *almost* feasible, because build_all passes 
arguments through to child make processes.

Unfortunately, because the Fast Downward makefiles use "CC" as the variable for 
the C++ compiler, and VAL (I think more correctly) uses "CC" for C and "CXX" for 
C++, it's not possible to specify an alternate compiler in the command line to 
build_all.

I believe that the correct solution would be to revise the FD Makefiles to use 
CXX instead of CC; then one could do something like

./build-all CXX=/opt/local/bin/g++ CC=/opt/local/bin/gcc

I'd be willing to provide a patch, but don't want to do so if this would be 
wrong for some reason.