On Jul 6, 2007, at 3:57 AM, Simon Marlow wrote:
Peter Tanski wrote:
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.
Definitely. The reason for duplication was intentional:
enforcement. At least initially, there is only one way to build the
system and even if configure messes up (which it will) build.mk.msvc
would have been listed last to override the incorrect value.
Together, build.mk.msvc and msvc_tools are the system-specific
configuration "file" I was trying to explain earlier. I admit, it is
a bit rigid.
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?
No reason I can't; I just don't want to. With all these variables
gathered together in one place it becomes trivial to review them
there and change them in both the Make and GHC worlds and it is
better to coordinate the two. It is also easier for someone who
does not know CL options to look at, say clOmitFramePointer in GHC
and know what it means instead of having to go and look up what the
string "-Oy" means. (I may be a stickler but at least for reasons
normative rather than procedural: this is just an easier layout read
and modify. If I had my way the NCG, for example would be based on a
"machine specification" for each architecture--worlds easier than
hasktagging through 8 or 10 different Emacs sessions to find how
everything fits together.) Everything is done in GHC, except the
argument-warnings. Note that the Make-function defines at the end of
msvc_tools.mk are wrong: "command files" or "response files" require
each argument on its own line; this is done properly in GHC, if the
command line exceeds a conservative estimate of command line
(character) length. There is a long note on that in the revised
compiler/main/SysTools.lhs. I hadn't gotten around to deleting the
defines, though they are currently unused. This is your program,
though, so if you want me to change this I will.
Cheers,
Pete
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
