On 9/13/12, Ian Lynagh <i...@well-typed.com> wrote:
> On Thu, Sep 13, 2012 at 05:12:56AM -0700, Gabor Greif wrote:
>>
>> Btw., Ian is working in this area on the master branch so
>> there will be a bunch of conflicts anyway :-(
>
> Sorry, I hadn't realised you were working on this in a branch. If
> merging your changes to master is possible (i.e. if they don't break the
> build, even if what they add isn't actually used yet) then I'd recommend
> doing that, to avoid conflicts.
No worries, I like the direction you going :-)
I just cannot work full time on the branch (mere few hours a week),
so I am always lagging behind. You guys are a productive bunch...
>
>
> It's starting to feel like we're close to a full cross-compilation
> compiler, incidentally. I'm currently working on getting all the
> platform-specific values into a platformConstants file, which is read by
> the compiler at run-time. Once that's done, modulo a handful of bits of
That is fine, as my branch's main contribution is to interrogate a cross-gcc
about what those constants are, and to make them available to
mkDerivedConstants.c.
Did you look into the mechanism how this is done? In short, I create an .o file
that has objects whose *size* equals the platform constants. I extract the sizes
via 'nm' and create the SizeMacros.h. This in turn gets included by
mkDerivedConstants.c.
> CPP etc that remain, it ought to be possible to make a single-platform
> cross-compiler simply by substituting the 'settings' and
> 'platformConstants' files with those from another platform. In reality,
> we'll probably find more places where "target = host" assumptions are
> getting baked in, but we'll have to deal with those when we come to
> them.
Yes.
>
> The other half of the puzzle (perhaps what you're looking at) is
> altering the build system to be able to (a) generate 'settings' and
> 'platformConstants' files for platforms other than host, and (b) build
Yes. See above.
> for multiple platforms in a single tree. I suspect that (a) means
Actually, I am happy with one HOST != TARGET platform per GHC already.
> getting rid of mkDerivedConstants, and using a configure script instead,
> but I haven't really thought about this half yet.
Yes, this is part of the plan, but can probably wait. Passing around the
autoconf cache file to sub-configures is probably more lucrative short-term.
Cheers,
Gabor
>
>
> Thanks
> Ian
>
>
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
