Unclear how to use --no-gnu and --no-blocks with Cabal

[dcoutts]

At least one author has found that they need to specify one of these flags to get their stuff to work on OSX. This throws up the issue of how that integrates with Cabal.

I'm not totally clear on when these flags are needed:

• Are these flags something that should always be set by Cabal based on the platform we're building on? If so, should they just be the c2hs defaults, or is it something Cabal should always pass to c2hs?
• If they're not global to the platform, are these flags things that authors need to know to specify (e.g. because they're required to be set for some header files and required not to be set for others)? If so, the right thing would be for them to be in-file directives (like the other file-global directives like {# context #}).

At the moment it's impossible to use either flag from a Cabal package because there's nowhere for the author to specify them. We do not wish to add a c2hs-options field to the .cabal file: in allmost all cases flags should be set automatically by the build system (like --cpp) or author-specified directives should live inside the files.

[ian-ross]

Yeah, I was never quite sure how these were going to be used. I implemented them the way that I did mostly to flush out this sort of question (when I started looking after C2HS, it wasn't quite clear which issues on the old Trac were still "live"; I also don't have an OSX or Windows machine to test these things on, so I was groping around a little). Here's my understanding of things:

• The --no-blocks option should be used whenever compiling on OSX (I think it's true that that's the only platform where you ever see this "blocks" extension, isn't it?) but probably doesn't do any harm on other platforms;
• The --no-gnu option is harder to deal with: sometimes it should be used when compiling with a non-GCC compiler, but sometimes it shouldn't (issue Should not define preprocessor symbols for GCC #51 is one that claims it should be, but issue c2hs rejects mingw32's stdlib.h #60 turned up a case where it shouldn't).

I can't say for sure that either of those statements is 100% correct, but it seems as though the --no-blocks thing should be turned on by default everywhere (i.e. it shouldn't even be an option) and the --no-gnu thing should be configurable on a case-by-case basis within the CHS file using a file-global directive in the way you suggest.

Can you think of any objections to doing things that way?

[ian-ross]

@dcoutts Here's what I've done for this now:

• Removed the --no-blocks and --no-gnu command line options.
• Always undefine the __BLOCKS__ preprocessor symbol.
• Added a {#nonGNU#} directive to signal that GNU-specific preprocessor symbols should be undefined during processing of a CHS file.

I think that's the best approach to deal with this: the blocks stuff we can never deal with because language-c doesn't support it, and the GNU stuff is now controlled from within the CHS files, which is where the include statements pulling in headers that might have a problem with GNU defines live.

[mietek]

Thanks. Always undefining __BLOCKS__ is definitely the right approach for as long as language-c doesn't support them.