frozenbubble2 cannot build with llvm-cpp-4.2

[anddam (Andrea D'Amore)]

When building frozenbubble2 after ​clang has been blacklisted and ​added to build.args I get an error because llvm-cpp-4.2 cannot accept multiple input files as it is requested to in server/Makefile

I'm attaching a patch to fix it.

Also please make the port openmaintainer.

[anddam (Andrea D'Amore)]

Also, the port needs a license.

[jmroot (Joshua Root)]

Log? This built fine on the Lion buildbot with llvm-gcc-4.2.

[anddam (Andrea D'Amore)]

Replying to jmr@…:

Log? This built fine on the Lion buildbot with llvm-gcc-4.2.

It builds fine as long as you don't set CPP in build.args, but since I did set CC (this is not clang) I set CPP to ${configure.cpp} and this breaks building, here's the relevant part:

make[1]: Entering directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_trunk_dports_games_frozenbubble2/frozenbubble2/work/frozen-bubble-2.2.0/server'
/usr/bin/llvm-cpp-4.2 -g -Wall -Werror -pipe  -I. `pkg-config glib-2.0 --cflags` -DVERSION=\"2.2.0\" -M fb-server.c log.c tools.c game.c net.c > .depend
llvm-cpp-4.2: too many input files
make[1]: *** [.depend] Error 1
make[1]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_trunk_dports_games_frozenbubble2/frozenbubble2/work/frozen-bubble-2.2.0/server'
make: *** [dirs] Error 2
make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_trunk_dports_games_frozenbubble2/frozenbubble2/work/frozen-bubble-2.2.0'
Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_trunk_dports_games_frozenbubble2/frozenbubble2/work/frozen-bubble-2.2.0" && /usr/bin/make -w all V=1 PREFIX="/opt/local" CC="/usr/bin/llvm-gcc-4.2" LD="/usr/bin/llvm-gcc-4.2" CPP="/usr/bin/llvm-cpp-4.2"
Exit code: 2

Is using *gcc -E the same/better/worse compared to using actual preprocessor executable'?

Attaching same patch as before on top of r98202.

[jmroot (Joshua Root)]

Replying to and.damore@…:

Is using *gcc -E the same/better/worse compared to using actual preprocessor executable'?

No, just "different". This is why we don't set CPP in the default configure phase.

Closing given that this patch introduces the very problem it solves.