ghc @7.8.3_2: setting compiler.cpath and compiler.library_path is potential no-op

[howarth.at.macports@…]

While adapting the MacPorts ghc-bootstrap/ghc to create matching fink packages to build ghc from source for adding rootless support to 7.8.3, I noticed what appears to be a thinko in the current ghc Portfile. Specially, the section...

# OK so because the bootstrap binary has been prebuilt for libraries
# in /usr/lib we search these before macports stuff to prevent
# link errors, ghc _should_ actually compile itself in stage2
# using paths from the command line arguments
compiler.cpath /usr/include
compiler.library_path /usr/lib

seems to be a pointless no-op since it adds those directories to the search list *after* the -I and -L entries are processed.
In the fink packaging, it was desired to mimic the upstream ghc binaries as closely as possible so...

--with-iconv-includes=/usr/include \
--with-iconv-libraries=/usr/lib \

was used in concert with

NoSetCPPFLAGS: true
NoSetLDFLAGS: true

Interestingly this still required a BuildConflicts on the fink libiconv-dev to prevent a build issue with ghc-pandoc-types...

[57 of 57] Compiling Text.Pandoc      ( src/Text/Pandoc.hs, dist/build/Text/Pandoc.o )
In-place registering pandoc-1.12.4.2...
Preprocessing executable 'pandoc' for pandoc-1.12.4.2...
[1 of 1] Compiling Main             ( pandoc.hs, dist/build/pandoc/pandoc-tmp/Main.o )
Linking dist/build/pandoc/pandoc ...
Undefined symbols for architecture x86_64:
  "_libiconv", referenced from:
      _hs_iconv in libHSbase-4.7.0.1.a(iconv.o)
  "_libiconv_close", referenced from:
      _hs_iconv_close in libHSbase-4.7.0.1.a(iconv.o)
  "_libiconv_open", referenced from:
      _hs_iconv_open in libHSbase-4.7.0.1.a(iconv.o)
ld: symbol(s) not found for architecture x86_64

In the MacPorts case, since you using...

--with-iconv-includes=${prefix}/include \
--with-iconv-libraries=${prefix}/lib    \

and are leaving -I${prefix}/include on configure.cppflags and -L${prefix}/lib on configure.ldflags, the use of...

compiler.cpath /usr/include
compiler.library_path /usr/lib

is pointless dead code in the Portfile

[howarth.at.macports@…]

One other potential enhancement to the current Portfile. If you use...

        --with-ffi-includes=${prefix}/include \
        --with-ffi-libraries=${prefix}p/lib \
        --with-system-libffi \

and include

port:libffi

in the depends_lib, it should suppress the build of the bundled libffi sources in ghc and build/link against the MacPorts libffi instead.