On 12/05/2011 07:58, Ben Lippmeier wrote:
Hi All,
I thought I'd take a moment to mention that the GHC build system is basically
unmaintainable by anyone except the original authors. It's clear that a heroic
effort has been made to fit a square peg into a round hole, and I *want* to
help, but stuff like this makes my eyes hurt:
$$($$($1_PACKAGE)-$$($1_$2_VERSION)_HADDOCK_DEPS) | $$$$(dir $$$$@)/.
So does this:
$$(foreach pkg,$$($1_$2_DEPS),$$(if
$$($$(pkg)_HADDOCK_FILE),--read-interface=../$$(pkg)$$(comma)../$$(pkg)/src/%{MODULE/./-}.html\#%{NAME}$$(comma)$$($$(pkg)_HADDOCK_FILE)))
One day maybe this will all get replaced by something beautiful. Until
then you have to read the docs to undestand how to decode it:
http://hackage.haskell.org/trac/ghc/wiki/Building/Architecture
The syntax is indeed horrible, but we did go to some trouble to document
the "idioms". If you understand those then you should be able to decode
lines like the above.
e.g. inside a macro you have to double all the $ first of all. So
that's a layer of encoding easily understood.
http://hackage.haskell.org/trac/ghc/wiki/Building/Architecture/Idiom/Macros
the $$$$(dir $$$$@)/. stuff is an idiom:
http://hackage.haskell.org/trac/ghc/wiki/Building/Architecture/Idiom/Directories
The $1_$1_ stuff is an idiom:
http://hackage.haskell.org/trac/ghc/wiki/Building/Architecture/Idiom/VariableNames
If you read the docs and still can't make any sense of something, then
we should probably fix the docs (or rewrite that bit of code).
You can get a long way to understanding what's going on with
printf-debugging:
http://hackage.haskell.org/trac/ghc/wiki/Building/Modifying
and this:
$$(foreach p,$$(patsubst libraries/%,%,$$(wildcard $$(shell grep '^[^ #][^
]* \+\(dph\|extra\) \+[^ ]\+ \+[^ ]\+ \+[^ ]\+' packages | sed 's/ .*//')))
I once heard that you should write your code like it'll be read by a psychotic
axe murder that knows where you live. Suffice to say, I don't own any axes, nor
am I planning on buying any. Axes aren't really my thing. What *is* my thing is
helping to write GHC, but this is very difficult when faced with write-only
code.
:( I blame the tools.
Still, that line isn't *too* difficult to understand, you just have to
break it down and understand what each piece does.
If you want some make code that is hard to understand, try this:
define ap
$(strip \
$(if $(findstring $(dollar),$1$2),\
$(dollar)$(lpar)call ap$(comma)$1$(comma)$2$(rpar),\
$(if $(findstring >>$(lpar)PAP,>>$1),\
$(subst $(space)<-TMPSPACE,$(comma),\
$(patsubst >>$(lpar)PAP_%,$(dollar)$(lpar)call %$(comma)$2,\
>>$(subst $(comma),$(space)<-TMPSPACE,$1))),\
$(dollar)$(lpar)call $1$(comma)$2$(rpar))))
endef
That's my implementation of combinator reduction in GNU make.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
