.h files not found when compiling via C

[Duncan Coutts]

On Thu, 2006-08-03 at 12:57 +0200, Volker Wysk wrote:
> On Tuesday 01 August 2006 19:54, you wrote:
> > On Sun, 2006-07-23 at 18:09 +0200, Volker Wysk wrote:
> > > Hello
> > >
> > > When compiling a module, which contains "foreign import" directives, via
> > > C, the C compiler needs to be passed a "-I." argument, otherwise the
> > > include file mentioned there won't be found.
> > >
> > > You can do this manually with an "-I." argument to ghc (after you figure
> > > it out), but since this is always necessary, I consider it a bug.
> >
> > I believe this behaviour was changed in GHC 6.4 or perhaps it was 6.2. I
> > forget. Anyway, it was deliberate (I think!). Remember that you can
> > include things from the system's standard include search path without
> > specifying -I, so you don't always have to use -I. You only need it if
> > you are using local .h files, in which case, the argument goes, why not
> > be explicit about that fact? That's one rationale for the change.
> 
> It shouldn't matter if you compile via C or not. In my case, I turned 
> optimization on, which made the compilation be done via C, and it wouldn't 
> compile any longer. 

Yes, that is confusing.

> The .h files are generated by c2hs. So you need an "-I." option when using 
> c2hs, but this shows only when compiling via C. That's something I didn't 
> know. 
> 
> I also don't want to need to know about those "foreign import" directives, 
> since I never write them directly.

That's a good point. Perhaps cabal should use -I. when the project uses
c2hs.

> So you can consider this not a bug, but it sure will lead to frustration of 
> people who want to compile Haskell programs with optimization. Maybe the 
> compiler should warn about .h files which can't be found, even if they aren't 
> used right now...

That would be a good idea. At least for header files specified directly
in ffi imports.

Duncan