darcs patch: Put pre-processed source into the dist/b... (and 2 more)
Those patches I was talking about. I'd apreciate a review :-) Actually to test it with c2hs also needs a patch to c2hs that I'll send tomorrow. But it should work for alex & happy etc already. Duncan Sun Apr 22 19:56:31 EST 2007 Duncan Coutts <duncan.coutts@worc.ox.ac.uk> * Put pre-processed source into the dist/build dir rather than src dirs This is generally just a nicer thing to do, we should probably aim to not write any files into the source tree at all. The main change is in the preprocessModule function. It now takes an extra arg which is the destination directory. For now I'm passing the buildDir, but we could consider putting pre-processed files into a separate fir from where the .o and .hi files end up. To work out the correct destination file we need to know not only the source file but which of the search dirs it was found in, since the relative file name will be the name of the source file relative to the search dir it was found in, not the name relative to the top of the source tree. This is so that we will be able to find the pre-processed .hs file just by adding dist/build to the sources search path when we compile (eg with -i for ghc). This almost certainly breaks the sdist thing where pre-processed files get included into the tarball. So that'll need looking at. Sun Apr 22 20:05:58 EST 2007 Duncan Coutts <duncan.coutts@worc.ox.ac.uk> * Generalise PreProcessors to take more detailed args Most pre-processors just need the full source file and target file names. More complicated ones where the generated files have to embed links to each other need more information. For example c2hs generates .hs file that reference generated .h files. These links should be relative to the dist/build dir and not to the top of the source tree, since we do not want to add -I. to the includes search path. We only want to use -Idist/build, hence the embeded links must be relative to that. Therefor c2hs needs to know the base output directory as well as the name of the file relative to that. So we add a new type PreProcessorFull that has this extra info and a function simplePP :: :: PreProcessor -> PreProcessorFull for the common case of most existing pre-processors that do not need this extra info. This patch doesn't actually change the c2hs stuff, that comes next. Sun Apr 22 20:26:17 EST 2007 Duncan Coutts <duncan.coutts@worc.ox.ac.uk> * call c2hs using the more detailed info we use --output-dir=dist/base and --output=<file relative to the search dir it was found in>.hs This actually depends on a patch in c2hs to make it treat --output-dir in the way we want. That patch will be forthcomming soonish. But the point is: c2hs --output-dir=dist/base --output=Foo/Bar.hs src/Foo/Bar.chs will generate dist/base/Foo/Bar.hs and also dist/base/Foo/Bar.h but inside the .hs file it'll reference Foo/Bar.h so when we compile the .hs file we have to -Idist/base Clear as mud?
Duncan Coutts wrote:
Those patches I was talking about. I'd apreciate a review :-)
Looks fine - although as we talked about on IRC, we should think carefully about what sdist is supposed to do, and the difference between Happy/Alex-generated .hs files and c2hs-generated .hs files. The former should go in an sdist, but not the latter. Cheers, Simon
On Tue, 2007-04-24 at 09:52 +0100, Simon Marlow wrote:
Duncan Coutts wrote:
Those patches I was talking about. I'd apreciate a review :-)
Looks fine - although as we talked about on IRC, we should think carefully about what sdist is supposed to do, and the difference between Happy/Alex-generated .hs files and c2hs-generated .hs files. The former should go in an sdist, but not the latter.
Indeed. We need to know for each pre-processor if the generated .hs files are platform and implementation independent. As Ross points out, currently we don't do anything about implementation independence, we generate alex & happy .hs files that use ghc extensions and then include them in the sdist tarball. Duncan
participants (2)
-
Duncan Coutts -
Simon Marlow