[89248] trunk/dports/science/alliance/Portfile

[Rainer Müller]

Hello,

problems such as this should not result in a switch of the compiler and
pulling in the huge apple-gcc42 port. This can be fixed with simpler
methods than ruling out clang. See also Clemens' mail in which he
recently explained the situation on implicit assumption about the
compiler [1].

In this case, the original four errors were all of this type:

  elp.c:252:1: error: non-void function 'elpLotrsShrink' should return a
value [-Wreturn-type]

When looking at the reported source location, this is an obvious error
in the statement "return;". This can be fixed with a patch by changing
this to "return 0;" as the return value of this function is never used
anyway. Or just change the function declaration to void.

As an alternative, this can be fixed by using CFLAGS to make clang less
strict about the problems in this file - in the same way gcc only
generates a warning and does not error out for this problem.

Anyway, there is definitely no need to use a different compiler or even
force building of the apple-gcc42 port.

Here are the options:

a) Make clang less strict with an option in the Portfile:
   configure.cflags-append -Wno-return-type

b) Do the same as a) but with a patch to the Makefile in the
   subdirectory to apply it only locally.

c) Apply a patch to eliminate this wrong "return;", also submit it
   upstream.

Remember that llvm-gcc42 will most probably also not be available
forever and it's already four releases behind the mainline gcc used on
other platforms.

Rainer

[1]
http://lists.macosforge.org/pipermail/macports-dev/2012-January/017470.html