C++

[ekmett]

This project is so close to being equally suitable for C++ development.

The problem seems to be just that there is no good way to indicate other than changing the compiler that the generated source should be treated as c++ rather than c.

Something like handling .hscc and having that produce a _hscc.cc file, and feeding it to a c++ compiler would basically be enough.

[simonmar]

Strangely enough I've just been investigating this for some code that we're planning to open source. Here's the landscape at the moment:

• To use c++ you can currently add --cc=g++ --ld=g++). BUT:

  • This doesn't work with Cabal, because
    • Cabal has no hsc2hs-options field in .cabal files, so you have to add --hsc2hs-options on the command line, which then applies to all packages (easy to fix, but needs to be upstreamed into Cabal)
    • Cabal adds its own --cc option to set the compiler to whatever --with-gcc is in force, which is the right thing to do. But hsc2hs implements flag parsing wrongly, so Cabal's --cc option overrides a later one, meaning we can't use hsc2hs-options to set --cc.
    • You can do --with-gcc=g++ on the command line but again that's not a sustainable solution

• We could change hsc2hs to recognise .hscpp or .hscc and generate _hsc_make.cpp instead. That works for compiling, but for linking you also need -lstdc++

• We could add a --c++ option to hsc2hs, which would cause it to generate a _hsc_make.cpp, as above. In fact we could do both this and the previous point.

What I propose to do is:

• In the short term:
  • modify Cabal to put its --cc options at the end of the command line, so they can be overriden
  • Add an hsc2hs-options field to the .cabal syntax
  • Recommend use of hsc2hs-options: --cc=g++ --lflag=-lstdc++
• Longer term:
  • Make hsc2hs recognise .hscpp and .hscc as above
  • Add a --c++ option to hsc2hs
  • (note that with both of these you may also need hsc2hs-options: --lflag=-lstdc++)

[hvr]

But hsc2hs implements flag parsing wrongly

are we committing to remain bug-compatible with those semantics, or is hsc2hs gonna "fix" this in a future version to apply the usual "rightmost flag overrides leftmost flags" convention? it's no big deal if it's fixed, just something that needs to be taken into account as then we need to version-gate this (i.e. the "put --cc at the end" thing) against hsc2hs' reported version in the lib:Cabal code defensively

[simonmar]

I have no strong feelings... obviously it's a lot of hassle to fix it, but if you feel motivated then go for it.

[simonmar]

This pull request adds hsc2hs-options: haskell/cabal#6295

[Mistuke]

note that with both of these you may also need hsc2hs-options: --lflag=-lstdc++

You shouldn't need this though, if you've changed the driver from gcc to g++ then the default spec file should have added libstdc++ already.

You can probably also use gcc with -xc++ -lstdc++, but yeah using g++ directly is the best option.

[simonmar]

I actually use ghc as the linker for hsc2hs (see simonmar/cabal@c2ff41c). It's possible I could also use -pgml g++, but I think I found that -lstdc++ worked fine, so I went with that.

[Gabriella439]

@roberth taught me that you can add hsc2hs-options: --cc g++ or hsc2hs-options: --cc clang++ to your .cabal file to work around this

[ekmett]

@Gabriella439 Yep. That should be the case now, given the patches since this bug was filed. At the time, you couldn't override correctly because the argument order caused the things asserted by cabal to override.

We now have hsc2hs-options (haskell/cabal#6295) and they should properly override (#35) unlike back then.

I'd still like a clearer ability to mix and match c and c++ hsc2hs in the same library though.