On Jan 20, 2009, at 17:10, Peter Gavin wrote:
>> -itools/c2hs/base/admin:tools/c2hs/base/errors:tools/c2hs/base/ 
>> general:tools/c2hs/base/state:tools/c2hs/base/syms:tools/c2hs/base/ 
>> syntax:tools/c2hs/c:tools/c2hs/chs:tools/c2hs/gen:tools/c2hs/ 
>> state:tools/c2hs/toplevel -package-conf package.conf.inplace -hide- 
>> all-packages -package base-3.0.1.0 -package haskell98-1.0.1.0 - 
>> package pretty-1.0.0.0 -package containers-0.1.0.1 -package  
>> array-0.1.0.0
>>
>> tools/c2hs/base/errors/Errors.hs:44:0:
>>      Failed to load interface for `Position':
>>        Use -v to see a list of the files searched for.
>>
>> when generating the dependencies. I saw that you pushed a patch  
>> were you
>> avoid a recursive invocation of 'make'. This might have caused it.  
>> The
>> dependencies in c2hsLocal.deps are correct but I think they are not
>> honoured by 'make' if it is not invoked recursively.
>>
>> Interestingly, the build continues and c2hs is built correctly on  
>> Linux.
>> On Mac OS, the build stops with the error above.
>>
> Hmm...   I know why that error happens (and was expecting it to)  
> but I'm surprised the build fails for you.  What is happening is  
> that when make starts, it tries to read all the included .dep  
> files, which of course don't exist.  So it tries to do what it can  
> with the rules it has to build those files.  The first thing it  
> tries to build is the deps for c2hs.  Once it does that, it  
> continues building as far as it can (which is up until it gets to  
> that Errors.hs file), after which it re-reads all the .dep files it  
> can and starts completely over from scratch.  It seems on your Mac  
> installation make is quitting entirely, instead of just rereading  
> the .dep file and building the c2hs sources in the correct order.   
> What I wanted to figure out is if there was a way to have make  
> reread a .dep file immediately after it's generated, instead of  
> trying to build all the other .dep files first, then rereading them  
> when that fails.  So it sounds like your linux maching behaved the  
> way I expected to, but your Mac didn't.
>
> I think I might have a solution for this, but I'm still thinking  
> about it.  In the mean time, running make twice should work fine  
> and give correct results.
>

This sounds rather brittle. The magic with

-include blah.deps

is that GNU make will try to make blah.deps, thereby triggering a  
recursive call to make which builds c2hsLocal and all .hs files and  
runs ghc to calculate dependencies. When the recursive make is done,  
the outer make will slurp in the dependencies in blah.deps as if they  
were always there. (The minus sign in front of include merely says it  
shouldn't raise a fatal error if the .deps file cannot be found. We  
could actually omit that I think.)

I admit this is rather subtle. Indeed, this is the reason we're not  
yet using Cabal.

So, under these consideration, your patch

hunk ./mk/common.mk 201
-.chs.hs: [_$_]
- $(strip if test -x $(C2HS); then :; else \
- $(MAKE) $(AM_MAKEFLAGS) $(C2HS); fi;)
- $(strip if test -f $($(PKG)_PRECOMP); then :; else \
- $(MAKE) $(AM_MAKEFLAGS) $($(PKG)_PRECOMP); fi;)
+.chs.hs: $(C2HS)


that removed the recursive call to make breaks this hack since now  
the dependencies are part of the main make file. I think it breaks  
because make first re-invokes itself to build c2hsLocal, then it re- 
invokes itself to build c2hsLocal.deps.

Sincere apologies for leaving you in the dark about this hackery.  
Another point I should raise is that the lines

ifeq (,$(findstring clean,$(MAKECMDGOALS)))
-include tools/c2hs/c2hsLocal.deps
  endif

have a similar evilness: The space before the endif exploits a bug in  
automake that fails to recognize the ifeq .. endif clause which it  
would otherwise translate into something else.

There might be more subtleties in our glorious makefile, but for now,  
I can't remember any more.

GNU make -- it's a love-hate relationship,
Axel.


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Gtk2hs-devel mailing list
Gtk2hs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel

Reply via email to