Lens doesn't build with --ghc-options="-pgmP cpphs -optP "

[cartazio]

``
Preprocessing library lens-4.0.7...

src/Control/Lens/Setter.hs:55:5: parse error on input ‘assign’
cabal: Error: some packages failed to install:
lens-4.0.7 failed during the building phase. The exception was:
ExitFailure 1
``

the associated CPPHS invocation being

*** C pre-processor:
cpphs '-DTRUSTWORTHY=1' -DINLINING -include dist/dist-sandbox-61f2ed31/build/autogen/cabal_macros.h --cpp -I dist/dist-sandbox-61f2ed31/build -I dist/dist-sandbox-61f2ed31/build -I dist/dist-sandbox-61f2ed31/build/autogen -I dist/dist-sandbox-61f2ed31/build -I /usr/local/lib/x86_64-osx-ghc-7.8.0.20140311/vector-0.10.9.1/include -I /usr/local/lib/x86_64-osx-ghc-7.8.0.20140311/primitive-0.5.2.1/include -I /usr/local/lib/ghc-7.8.0.20140311/time-1.4.1/include -I /usr/local/lib/ghc-7.8.0.20140311/bytestring-0.10.4.0/include -I /usr/local/lib/ghc-7.8.0.20140311/base-4.7.0.0/include -I /usr/local/lib/ghc-7.8.0.20140311/integer-gmp-0.5.1.0/include -I /usr/local/lib/ghc-7.8.0.20140311/include '-D__GLASGOW_HASKELL__=708' '-Ddarwin_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Ddarwin_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-U __PIC__' -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp src/Control/Lens/Setter.hs -o /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc53445_0/ghc53445_34.hscpp

I don't know if this is a lens issue or a cpphs issue, and I'm personally not equipped to sort it out myself.

[cartazio]

This is part of my work on https://ghc.haskell.org/trac/ghc/ticket/8683 to decouple ghc from needing to use the C compiler for CPP.

Looks like its a cpphs bug. reporting it here

[glguy]

The problem is that lens defines operators with "//" which cpphs interprets as a single-line comment.

[malcolmwallace]

You can turn off C++ style comments with an option to cpphs.

[cartazio]

@malcolmwallace which option flag is that? If we wind up shipping CPPHS with ghc for the 7.8 release cycle, would be nice to give it the right default flags!

i was just using --cpp

[glguy]

There actually appears to be a bug in how cpphs calls its "tokenise" [sic] function. The first two arguments are stripEol and stripC89 but they are swapped at the call sites. (Just from a cursory look at 1.8.3's source code)

[glguy]

With that fix I was able to build lens using --ghc-options="-pgmP cpphs -optP-traditional -optP--cpp"

[malcolmwallace]

Good spot. Thanks glguy. [P.S. "tokenise" is cromulent spelling for a Brit]

[cartazio]

@glguy @malcolmwallace i thought cpphs was always in -traditional mode?

[malcolmwallace]

When cpphs is called by ghc, it gets set to -traditional mode, yes. But traditional mode strips C89 comments, leaving C++ EOL comments intact. If the flags were accidentally swapped internally, that would explain the confusion.

[cartazio]

@malcolmwallace i don't understand the sentence When cpphs is called by ghc, it gets set to -traditional mode, yes

either ghc passes --cpp --traditional to the CPP program or not, what flags must GHC pass to cpphs (such as would be set by -optP) to work as expected? Exactly what @glguy pasted before or something else?

[malcolmwallace]

I do beg your pardon, I was mis-remembering the behaviour of the cpp-compatibility options for cpphs. So, -traditional is not the default, as glguy says. You can add it with -optP--cpp -optP-traditional. Or alternatively, you can use -optP--cpp -optP-CC to retain all C-style comments (-CC is a standard gcc cpp flag).

[cartazio]

to repeat my question: what flags should I have ghc default to passing to CPPHS for ALL haskell code? :)

(I'll need to pass this info along @thoughtpolice and @hvr for the 7.8.1 release :) )

[malcolmwallace]

Well, that depends somewhat on the source code to be processed. If the Haskell source code contains valid Haskell symbols // or /* or */ then you need to turn off comment-stripping; but if the CPP directives contain C-style comments, then you need to strip them. However I think any package that contains both CPP and the Haskell symbol // must already add the extra option -optP-CC (in the cabal file), otherwise how could it compile correctly?

[ekmett]

@malcolmwallace: lens currently doesn't depend directly on cpphs. The issue is @cartazio has been trying to work out how he can make the ghc wrapper use cpphs as a substitute for the classic gcc c preprocessor when running on Xcode 5, which sneakily substitutes in clang's stricter, less Haskell friendly C preprocessor.

Since lens has no knowledge if its being built by cpphs or gcc, I'm not sure how we could sensibly pass such a flag.

@cartazio: So it seems we're basically being killed by the //~, //=, <//~ and <//= operators?

I wonder if we can exile them to non-preprocessed modules as a hackish workaround in the meantime. Ugh.

[ekmett]

Hrmm, so I guess we can probably get away with just adding cpp-options: -traditional for now.

[cartazio]

@ekmett you could totally do a setup.hs hack to detect what the CPP program is and if its cpphs add the right flags to optP

[ekmett]

Honestly, that sounds pretty hard to do correctly and portably, comparatively.

[cartazio]

@ekmett its not the ghc wrap ..... austin is tentatively thinking of bundling cpphs with ghc 7.8.... and what i've been doing also makes it easier to change the cpp in user land.

but this does exhibit a good corner case if that happens. I don't think it will happen, but it could

[cartazio]

Soooo, if I had passed -cpp -traditional, rather than -cpp, this wouldn't have happened?

[hvr]

@malcolmwallace could we have cpphs --cpp --traditional behave a bit more like GNU cpp --traditional wrt c-comment stripping (specifically, only stripping /* */-comments, but not //-comments)?

[malcolmwallace]

So, cpphs --cpp -traditional is supposed to act exactly as you want: stripping /**/ comments, but retaining // comments. But there was a bug, identified by glguy, which meant cpphs got this wrong. Once I release cpphs-1.18.4, all should be good, I hope.

[hvr]

Thank you for clarifying; I'm looking forward to the cpphs-1.18.4 release then :-)

[malcolmwallace]

OK, cpphs-1.18.4 is now on hackage.

[glguy]

Thanks, Malcolm.

Edward has already added -traditional to the cpp-options, so that should wrap up this ticket.

[cartazio]

should -traditional need be added? GHC should always be setup up to do that ... ?

[ekmett]

Added it as a prophylactic measure. Willing to revisit it later.