Peter Tanski wrote:
On Jul 5, 2007, at 9:17 AM, Simon Marlow wrote:
Peter Tanski wrote:
... in mk/config.mk.in...
ifeq "$(TargetOS_CPP)" "windows"
< a whole boatload of extra settings >
endif
That would be better yes. I'm curious to see what the "boatload of
extra settings" are - there might be a better way to approach this.
The two (proposed) additions are attached below: build.mk.msvc does the
same job as build.mk.sample: it defines presets. It would probably be
no trouble to combine build.mk.msvc presets with msvc_tools.mk and
conditionally include them in boilerplate.mk, just before the
conditional include for .depends.
You've set some things in build.mk.msvc that should by set by config.mk instead.
For example, if SplitObjs needs to be NO for native Windows, then config.mk
should set it that way. It already does this for many of the variables you've
set in build.mk.msvc.
Msvc_tools.mk is essential,
especially all the extra variables that you might think aren't used in
build-variables: the Makefile from compiler/Makefile pipes those
variables into Configure.hs where I refer to them when setting the
compiler options in GHC--this way if I need to change the particular
layout I only have to do so in one place, for example, if someone wanted
to use ICL instead of CL or prepend each option with a '/' instead of a
'-'.
Personally I'd do away with msvc_tools.mk and put it all into GHC. You'd still
have it all in one place, but there'd be much less plumbing. Is there a reason
you can't do that?
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
