Cxx-Options for -std=c++11

[amigalemming]

In the llvm-ffi package I have C wrappers around C++ functions of LLVM in the file support.cpp. However, the C++ header files of LLVM-3.5 and later use new C++11 features. Thus I have added

CC-Options: -std=c++11

to llvm-ffi.cabal. Alternatively, I added -std=c++11 to the CFlags field of llvm.pc for use by pkg-config.
Now I get these warnings:

cc1: warning: command line option ‘-std=c++11’ is valid for C++/ObjC++ but not for C [enabled by default]

This is nothing serious, the package works fine. However, the warnings are annoying. Would it help to have a Cxx-Options field for Cabal descriptions? However, I do not know whether the Cabal file is the right place for the -std=c++11 option. Unfortunately, pkg-config does not have CxxFlags, too.

[23Skidoo]

We discussed this with @dcoutts once. Yes, there should be c++-options and c++-files, as well as a --with-c++-compiler command-line option. Same for objc and potentially other languages people want to use (Rust, Swift). Right now we're just passing c-files to GHC, which usually happens to work, but sometimes breaks down as in this example.

[ezyang]

I'm trying to understand what changes this would entail. Are we still going to invoke GHC to build these C++'ified headers? Then how do we pass these C++ headers; i.e., what exact flags do you want GHC to be invoked with?

@amigalemming , I think you can help here: can you run a build of your project with -v (or maybe a higher verbosity) and find the calls to ghc/gcc/whatever which are emitting the error. And then figure out what flags you actually wanted to be passed to this executable.

[23Skidoo]

Me and @dcoutts think that we shouldn't be using a Haskell compiler for building non-Haskell sources at all; we should just invoke gcc/g++/whatever directly instead. We should make sure that the right version of gcc is used by default, though (e.g. $GHC_DIR/mingw/bin/gcc on Windows, this information can be gained from ghc --info).

[amigalemming]

Recently I found that the issue was more serious on a Mac (or the gcc version installed there). On this Mac the -std=c++11 option for gcc was considered an error. :-(

[ezyang]

@amigalemming, would you be interested in helping contributing a fix to this problem? Would be happy to mentor.

[recursion-ninja]

I was hoping to use a convenience library described here to circumvent the issue by separating out the C++ code into the convenience library with differing cc-options flags from the rest of the library. However, as far as I can tell, it hasn't been released in the latest cabal version (1.24.2.0).

Having proper support for handling C++ files would be better. I'd be willing to attempt to make some progress on this front if @ezyang's mentoring offer still stands.

[ezyang]

So, the big problem is deciding on a reasonable design. The key existing code is in buildOrReplLib in Distribution.Simple.GHC; look for the comment -- build any C sources.

The current design is that for each C source file, we call GHC to build it. We do some work to compute the options (vanillaCcOpts, profCcOpts) in each case to make sure that it works with each of the compilation modes.

So the first thing to do is make a decision: are you going to build C++ with GHC (is this even possible? Sounds like it is, based on how people are putting C++ sources in c-sources), or teach Cabal how to lookup and interface with a C++ compiler? Former sounds easier, latter sounds "more correct" but could be a lot more work.

If you opt for the former, then adding support for C++ might be as simple as effectively copy pasting the C build code, but replacing all references to C with C++. Of course, you shouldn't actually do that; it would be better to refactor the code so it isn't duplicated, and there may be a lot of places in Cabal where c-sources is hard coded that need to be adjusted to handle cpp-sources (best to refactor this to use some centralized function.)

[recursion-ninja]

Thanks for the direction. I have a couple of irons in the fire right now, but hopefully I will be able to explore this over the next two weeks. I'll probably pursue the first, less correct but technically simpler approach you described.

[recursion-ninja]

Resolved by #4810