some quick notes on the experience of installing on shae's bladeserver - configure doesn't check for DrIFT (also check for other libs) - jhc/src/Doc doesn't exist in a clean install, I had to install a symlink from jhc/doc - jhc won't use multiple cores to build libs? might be a misunderstanding on my part. also, I've been thinking about a continuous integration server, both for JHC and for other projects. Shae's volunteered his machine, and I'm happy to set up a continuous integration environment, but I wanted to make sure that I wasn't duplicating work - have you got one already? Cheers Mark
On Tue, Aug 11, 2009 at 02:55:28PM +1000, Mark Wotton wrote:
some quick notes on the experience of installing on shae's bladeserver
- configure doesn't check for DrIFT (also check for other libs)
Well, the configure script is mainly for the benefit of the tarball, which should not require DrIFT to compile and install (if it does, that's a bug). If you are actually modifying the source/developing jhc, then a few more tools (like DrIFT and happy) are required.
- jhc/src/Doc doesn't exist in a clean install, I had to install a symlink from jhc/doc
Hmm... 'Doc' should be included in the tarball, if you are compiling from the darcs repository then you need to pull in that repository seperately.. it looks like the docs are wrong about where that needs to be pulled in (http://repetae.net/computer/jhc/development.shtml), I'll fix that.
- jhc won't use multiple cores to build libs? might be a misunderstanding on my part.
Jhc itself currently won't do it on its own, but you can create a suitable makefile and do 'make -j' which will utilize all your cores. My recent patches are paving the way for native parallel support in jhc, however a while ago someone tested it and found it didn't improve speed that much, it could have been an issue with the GHC runtime though... I would be interested in trying it again.
also, I've been thinking about a continuous integration server, both for JHC and for other projects. Shae's volunteered his machine, and I'm happy to set up a continuous integration environment, but I wanted to make sure that I wasn't duplicating work - have you got one already?
I don't think so, what do you mean by a continuous integration server? Like a buildbot style system? John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
On 12/08/2009, at 12:00 AM, John Meacham wrote:
On Tue, Aug 11, 2009 at 02:55:28PM +1000, Mark Wotton wrote:
some quick notes on the experience of installing on shae's bladeserver
- configure doesn't check for DrIFT (also check for other libs)
Well, the configure script is mainly for the benefit of the tarball, which should not require DrIFT to compile and install (if it does, that's a bug). If you are actually modifying the source/developing jhc, then a few more tools (like DrIFT and happy) are required.
Ah, fair enough. I'm running from darcs now.
- jhc won't use multiple cores to build libs? might be a misunderstanding on my part.
Jhc itself currently won't do it on its own, but you can create a suitable makefile and do 'make -j' which will utilize all your cores. My recent patches are paving the way for native parallel support in jhc, however a while ago someone tested it and found it didn't improve speed that much, it could have been an issue with the GHC runtime though... I would be interested in trying it again.
I meant for the actual build process of jhc itself - only interesting because I'd like to run a full build-and-test on each operating system on each commit.
also, I've been thinking about a continuous integration server, both for JHC and for other projects. Shae's volunteered his machine, and I'm happy to set up a continuous integration environment, but I wanted to make sure that I wasn't duplicating work - have you got one already?
I don't think so, what do you mean by a continuous integration server? Like a buildbot style system?
Yeah, exactly. I'm going to set one up anyway for some other haskell projects. It should really just be a matter of fiddling with regress.prl so it can spit out TAP - can just hook it up to a standard reporter after that. mark
On Wed, Aug 12, 2009 at 12:10:59AM +1000, Mark Wotton wrote:
I don't think so, what do you mean by a continuous integration server? Like a buildbot style system?
Yeah, exactly. I'm going to set one up anyway for some other haskell projects. It should really just be a matter of fiddling with regress.prl so it can spit out TAP - can just hook it up to a standard reporter after that.
Something like that would be great. :) John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
On 13/08/2009, at 3:59 PM, John Meacham wrote:
On Wed, Aug 12, 2009 at 12:10:59AM +1000, Mark Wotton wrote:
I don't think so, what do you mean by a continuous integration server? Like a buildbot style system?
Yeah, exactly. I'm going to set one up anyway for some other haskell projects. It should really just be a matter of fiddling with regress.prl so it can spit out TAP - can just hook it up to a standard reporter after that.
Something like that would be great. :)
Righto, on it. It needs a Rakefile to express the process of building the whole thing from scratch in the repo - you ok with that?
On Fri, Aug 14, 2009 at 11:06:59AM +1000, Mark Wotton wrote:
On 13/08/2009, at 3:59 PM, John Meacham wrote:
On Wed, Aug 12, 2009 at 12:10:59AM +1000, Mark Wotton wrote:
I don't think so, what do you mean by a continuous integration server? Like a buildbot style system?
Yeah, exactly. I'm going to set one up anyway for some other haskell projects. It should really just be a matter of fiddling with regress.prl so it can spit out TAP - can just hook it up to a standard reporter after that.
Something like that would be great. :)
Righto, on it. It needs a Rakefile to express the process of building the whole thing from scratch in the repo - you ok with that?
sure, as long as it doesn't break the normal makefile. Can you put it in the utils directory though? I am trying to keep the top level directory from getting too crowded. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
On 12/08/2009, at 12:00 AM, John Meacham wrote:
On Tue, Aug 11, 2009 at 02:55:28PM +1000, Mark Wotton wrote:
- jhc/src/Doc doesn't exist in a clean install, I had to install a symlink from jhc/doc
Hmm... 'Doc' should be included in the tarball, if you are compiling from the darcs repository then you need to pull in that repository seperately.. it looks like the docs are wrong about where that needs to be pulled in (http://repetae.net/computer/jhc/development.shtml), I'll fix that.
I think the instructions are still not quite right - this gives you a directory in jhc/Doc, where the Makefile requires a directory in jhc/ src/Doc. Cheers Mark
On Wed, Aug 12, 2009 at 04:16:17PM +1000, Mark Wotton wrote:
On 12/08/2009, at 12:00 AM, John Meacham wrote:
On Tue, Aug 11, 2009 at 02:55:28PM +1000, Mark Wotton wrote:
- jhc/src/Doc doesn't exist in a clean install, I had to install a symlink from jhc/doc
Hmm... 'Doc' should be included in the tarball, if you are compiling from the darcs repository then you need to pull in that repository seperately.. it looks like the docs are wrong about where that needs to be pulled in (http://repetae.net/computer/jhc/development.shtml), I'll fix that.
I think the instructions are still not quite right - this gives you a directory in jhc/Doc, where the Makefile requires a directory in jhc/ src/Doc.
Ah, yeah. That is because the web site is updated by my script that produces an official release. The documents have been fixed in darcs (doc/development.mkd). It would make more sense to have some pages (like that one) follow the darcs tree rather than the releases. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
participants (2)
-
John Meacham -
Mark Wotton