I am building ghc from source. The building page http://hackage.haskell.org/trac/ghc/wiki/Building/Using#Sourcetreesandbuildt... mentions lndir for separating source trees from build trees. Given how much detail is generally given for individual commands eg http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources maybe it would be nice to have a (typical?) lndir command also given? Also there is a mention about using a local git clone here http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources Arent these two alternative ways with similar intent - viz. keeping source pristine and separating build 'messiness'? Or do people use both git (local) clone + lndir? If so why? Rusi [ghc noob here: Please tell me if this is the wrong list to ask this kind of question :-) ]
On 15/11/2011 10:21, Rustom Mody wrote:
I am building ghc from source.
The building page http://hackage.haskell.org/trac/ghc/wiki/Building/Using#Sourcetreesandbuildt... mentions lndir for separating source trees from build trees.
Given how much detail is generally given for individual commands eg http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources
maybe it would be nice to have a (typical?) lndir command also given?
Sure. It's just $ mkdir <build> $ cd <build> $ lndir <source> but lndir is not a standard tool (any more), so you might have to build it yourself. There are sources in the GHC source tree in utils/lndir. Note the GHC build works perfectly well without a separate build tree, and I think that's the way most people do it.
Also there is a mention about using a local git clone here http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources Arent these two alternative ways with similar intent - viz. keeping source pristine and separating build 'messiness'? Or do people use both git (local) clone + lndir? If so why?
Right - arguably you can just clone a new source tree for each build that you want. I use separate build trees for two reasons: - my source trees are on a backed-up network file system, but the build trees are on fast local disk. - I can have several builds on different machines all using the same source tree. On my laptop the situation is similar, but my source trees are in my home dir which is an ecryptfs and the build trees are outside on the unencrypted partition. Not only is ecryptfs too slow for building on, it also doesn't work properly (there's some bug related to time stamps that I never managed to narrow down, it results in unnecessary rebuilding). You could do all this with git clones, but it would mean extra shuffling of patches around. If you're happy with that, then that's fine - use whatever scheme you're more comfortable with. Cheers, Simon
On Tue, Nov 15, 2011 at 04:47:18PM +0000, Simon Marlow wrote:
You could do all this with git clones, but it would mean extra shuffling of patches around. If you're happy with that, then that's fine - use whatever scheme you're more comfortable with.
There's a script in git's contrib directory called 'git-new-workdir'. You can use it to have multiple working directories that share the same git back end. I'll typically do something like: git clone ... mainsrc git new-workdir mainsrc worksrc cd worksrc git checkout -b work .. hack .. git add; git commit cd ../mainsrc git merge work # or cherry-pick or whatever test away I find it helps when making multiple patches to be able to test that the intermediate versions work, without having to mess up my main working tree. To install the script, just copy it somewhere into your path, and make it executable. Or make an executable script in your path like this: #!/bin/sh exec sh /usr/share/doc/git/contrib/workdir/git-new-workdir "$@" David
participants (3)
-
David Brown -
Rustom Mody -
Simon Marlow