Hi, I'd like to convert Yhc to use Cabal. This presents several challenges: * We would like to depend on fps/base depending on compiler version. Configurations will allow this. * We have the library Yhc.Core in our tree which is developed in parallel with Yhc. What would be nice is to have a Yhc.Core library which we don't have to explicitly install each time. I guess having all the Yhc.Core files in both the library, and again in the program would work. * We'd ideally like multiple cabal files in one directory - for things like ycr2js, yhc, yhi etc. * Can Cabal compile C files? Can it do things like testing the size of int/long etc? * Is cabal-install ready for serious use? If so we would like to use this as our primary method of compilation. I suspect that it will not be possible to move entirely to Cabal initially - but perhaps Yhc can point out features that Cabal lacks. Thanks Neil
On Wed, Jun 20, 2007 at 02:05:36PM +0100, Neil Mitchell wrote:
Hi,
I'd like to convert Yhc to use Cabal. This presents several challenges:
* We would like to depend on fps/base depending on compiler version. Configurations will allow this.
* We have the library Yhc.Core in our tree which is developed in parallel with Yhc. What would be nice is to have a Yhc.Core library which we don't have to explicitly install each time. I guess having all the Yhc.Core files in both the library, and again in the program would work.
* We'd ideally like multiple cabal files in one directory - for things like ycr2js, yhc, yhi etc.
* Can Cabal compile C files? Can it do things like testing the size of int/long etc?
* Is cabal-install ready for serious use? If so we would like to use this as our primary method of compilation.
I suspect that it will not be possible to move entirely to Cabal initially - but perhaps Yhc can point out features that Cabal lacks.
I beleive that the best approach would be to split the York build system into separate build systems for yhc/yhi/etc. Yhi, being a pure C program, can use a system designed for pure C, such as autotools. Yhc, being pure Haskell, would be a much better fit for Cabal than the York toolchain currently is considered as a whole. Stefan
Hi Stefan,
I beleive that the best approach would be to split the York build system into separate build systems for yhc/yhi/etc. Yhi, being a pure C program, can use a system designed for pure C, such as autotools.
Which doesn't really like Windows, so isn't really an option...
Yhc, being pure Haskell, would be a much better fit for Cabal than the York toolchain currently is considered as a whole.
The intention is to initially make Yhc compile with Cabal, and have "scons build yhc" just fork off Cabal to do the work. Gradually it would be nice to move more bits into Cabal. Thanks Neil
On Wed, Jun 20, 2007 at 03:15:23PM +0100, Neil Mitchell wrote:
Hi Stefan,
I beleive that the best approach would be to split the York build system into separate build systems for yhc/yhi/etc. Yhi, being a pure C program, can use a system designed for pure C, such as autotools.
Which doesn't really like Windows, so isn't really an option...
Ah yes. Windows is a good reason to pick scons over autotools.
Yhc, being pure Haskell, would be a much better fit for Cabal than the York toolchain currently is considered as a whole.
The intention is to initially make Yhc compile with Cabal, and have "scons build yhc" just fork off Cabal to do the work. Gradually it would be nice to move more bits into Cabal.
The York tools are very loosely coupled because of the documented IR. it seems kinda silly to force a common build system on them... Stefan
Stefan O'Rear wrote:
On Wed, Jun 20, 2007 at 03:15:23PM +0100, Neil Mitchell wrote:
Hi Stefan,
I beleive that the best approach would be to split the York build system into separate build systems for yhc/yhi/etc. Yhi, being a pure C program, can use a system designed for pure C, such as autotools. Which doesn't really like Windows, so isn't really an option...
Ah yes. Windows is a good reason to pick scons over autotools.
There's also cmake, which might be a better option. If you're not
already using scons, I wouldn't recommend it, based on painful
experience with its inflexibility.
On Wed, Jun 20, 2007 at 02:05:36PM +0100, Neil Mitchell wrote:
* We would like to depend on fps/base depending on compiler version. Configurations will allow this.
Although if you don't have base+bytestring then you'll have to compile a Cabal that supports configurations yourself. For older compilers you can just make an empty bytestring package, of course.
* We'd ideally like multiple cabal files in one directory - for things like ycr2js, yhc, yhi etc.
Why do you want that? Based on http://darcs.haskell.org/yhc/src/SConscript it looks like you pretty much have a directory per project, so why not put the .cabal files in those directories? You can then write a Setup.hs for the root such that, for example, "Setup build" builds all of the child cabal packages and "Setup build yhi" just builds yhi, for example. This root Setup.hs wouldn't actually use any of the Cabal API yet, although we might want to support meta-package .cabal files in the future, for exactly this sort of use.
* Can Cabal compile C files?
Yes.
Can it do things like testing the size of int/long etc?
No. Thanks Ian
participants (5)
-
Bryan O'Sullivan -
Ian Lynagh -
Neil Mitchell -
Simon Marlow -
Stefan O'Rear