Support building Objective-C modules

[bos]

(Imported from Trac #188, reported by guest on 2007-12-09)

GHC ignores Objective C sources unless -x c is passed to it on the command line before the source files.
As far as I could tell there is no way to pass that option to GHC through Cabal so no .m files ever get built (well.. not completely true - setting ghc-options works but that breaks compilation of Haskell code).

One way to get this to work would be to just add some extra code in Cabal to automatically pass -x c for .m files. This is probably a bad idea as someone might want or need to compile files using some other extension at some point.

Another option is add some way of specifying compile options on a per-file (or group of files) basis: setting ghc-options to -x c just for one set of files. Still very limited but it's an improvement over the first option.

Third option I can think of is to add a way of specifying compiler/extension pairs in Cabal so given compilers are automatically used to compile files with corresponding extensions.

Depending on how much time I have I might look into adding this functionality myself but would like some feedback on which approach to take.
Otherwise I might have to stick with autotools and ignore Cabal until it gets a bit more mature and flexible.

[bos]

(Imported comment by @dcoutts on 2007-12-09)

Cabal currently does not have a well abstracted way of supporting different kinds of files that can be compiled to .o files.

.c .m .c++ files are all different language files that can be compiled to .o files with their respective compilers. I don't think we should be trying to hack it by just pretending they're all .c files and passing different flags to ghc. They should use their own compiler directly and Cabal should be extended to cope with this more easily.

This would be much easier in a rule based, make style system. That work is at the pre-prototype stage at the moment (see #15). That should make it a lot easier to give a rule for building files with given extensions.

[bos]

(Imported comment by kazuya on 2007-12-10)

This is the obstacle to use GHC 6.10 with [HOC](Haskell to Objective-C binding), as mentioned here.

And the developer is yet to find a reasonable solution: http://code.google.com/p/hoc/source/detail?r=379

As solving this by full fledge make style system seems long shot, general FFI users as well as HOC users would be happier if this issue is somehow worked around by viz. specifying a special, ad-hoc rule.

[bos]

(Imported comment by @dcoutts on 2009-02-16)

If we want to support this in Cabal then we need to know how to build objective C modules. Personally I have no idea, I've never used objective C.

So supposing you listed the source objective C modules, what would Cabal need to do to build them? Is it any different from building C code?

For reference, see constructCcCmdLine in Distribution/Simple/GHC.hs.

[bos]

(Imported comment by mokus on 2009-02-16)

A more sophisticated system would probably be a good long-term solution to this type of situation, but in the interim I think a nice neat solution is to provide a means of telling Cabal "look, I made this .o! Put it in, coach!"

For GHC <6.10, this is already what HOC does, in a very kludgy way. It compiles the Objective C sources, then tells cabal that the resulting object file is a "c-source". That dirty little trick relies on GHC just ignoring the .o file when told to compile it as a C source. If we could say something like "intermediate-objects: HOC_cbits.o"in the cabal file it would take a little bit of the kludge out of it, and more importantly (to HOC users at least) it would allow HOC to build.

[bos]

(Imported comment by @dankna on 2009-03-16)

This appears to have been working for an indeterminate amount of time - you can specify .m files in c-sources and Cabal will hand them off to GHC, which will take care of figuring out that GCC is the appropriate backend and firing it off. So this ticket should probably be closed?

[bos]

(Imported comment by guest on 2011-05-28)

What version of GHC are you using?

See here for a somewhat recent ticket and fix related to this issue:
http://hackage.haskell.org/trac/ghc/ticket/5025

My understanding is that no released version of GHC supports this. I documented the things that I tried, without success, on that ticket. So if you have some way to do it without the fix in that ticket I would be interested to see your cabal file.

[bos]

(Imported comment by @dankna on 2011-05-28)

Ah, yes, I see that that fix was committed to GHC just seven weeks ago - which is barely older than my copy of ghc HEAD built from a git checkout. With that fix in place, everything "just works" for me. I listed the files in c-sources: and they worked fine. So it's in the pipeline towards release!

By the way, it's slightly spooky conversing with someone without a name - you should really register on Cabal's trac. :)

[tibbe]

Closing as there's been no activity in years.

We're cleaning up the bug tracker to make it useful again and are thus closing bugs that haven't seen any activity in a long time. Please re-open (or file a new bug) if the problem reappears.

[IreneKnapp]

Just for the record, I actually have interest in this still, as the initial reporter - having diligently kept track of this and related issues across the migration :). But I can vouch that the functionality is indeed working, as I used it last week. So, the ticket should be closed regardless.

[tibbe]

I'm glad it's now working!

Please don't interpret the closing of old bugs non-important. We just need to clean up the bug tracker if it's going to be a useful tool for planning our future work and with 500+ open bugs it isn't anymore.