Re: Test Suite's Dependency on Quickcheck
After further review, I can see that the test suite also requires 'network,' 'html,' and 'mtl' for all the tests to pass.Maybe we need to separate the packages into three groups: core, tests, and extras, where all the packages required by the test suite would get put into the tests group? Besides the dependencies on these non-core packages, there are 7 tests (maybe a couple more) that only work on Cygwin or Unix, but fail on MSYS/MinGW. Would you accept patches to these tests to make them run without Cygwin on Windows? The tests that would need to be patched are:* cabal01 and cabal02 Cabal is trying to execute ghc\compiler\stage2\ghc-inplace which is a shell script. Cabal expects it to be an executable.* process001, process002, and process003 These tests have c:/cygwin/bin/ls hard-coded into them, so they will fail on any system that doesn't have Cygwin in that exact location. * prog001, prog002, and prog003 These tests execute Unix commands like rm, and ls via :shell, so they fail on non-Unix/non-Cygwin systems.Tests requiring package 'QuickCheck': = SampleVar001 = Chan001 = MVar001 = QSemN001 = QSem001 = bytestring001 = bytestring004 = bytestring005 = ghci014 = maessen_hashtab Tests requiring package 'mtl': = mod133 = drvfail006 = drvfail008 = reify = tc183 = tcfail126 = tree Tests requiring package 'network' (and, transitively, package 'html'): = net001 = net002 = conc056 = pkg02_b = uri001On 9/12/06, Brian Smith [EMAIL PROTECTED] wrote: If you build GHC with just the default settings, QuickCheck doesn't get pulled from Darcs and it is thus not built and installed into ghc-inplace. Because of this, many of the tests in the test suite fail:SampleVar001 Chan001MVar001QSemN001QSem001bytestring001bytestring004bytestring005I think that the test suite should run without errors by default. What is the best way to deal with this situation? Probably the easiest thing to do would be to include QuickCheck as a core package as defined in the thread Packages in GHC 6.6. Then QuickCheck would need to be copied into the ghc-6.6 branch. Thoughts?- Brian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
compiler-independent core libraries infrastructure
(i crosspost my letter into main haskell list because i hope that proposed solution is of great interest for (discussion with) many developers) Hello Ian, Friday, September 8, 2006, 5:52:57 AM, you wrote: and last question - i don't like inclusion of unix and win32 in a list of core libs. why they are here? may be it's possible to include small modules with functionality required for compiler itself in GHC.* hierarchy and then move the rest into extra libraries? This doesn't work well for any parts shared with the other compilers. core libs is possibly the wrong name for it - bootstrapping libs might be more appropriate. Note also that unix and win32 haven't been included in anything they weren't already, it's just that other libraries (those that are now called extra libs) have been taken out. We can always take more out for 6.8 if we want. thank you - you have cleaned up the situation for me. thanks to Cabal, now ghc is much more modular than 6.4. but it is not yet the ultimate solution and i propose to discuss what we can do in future, possibly even in 6.6.1. i will become devil advocate for a little :) i am, John de MacLee programmer, never planned to build ghc itself and i don't need any bootstrapping libs in my download. please sell it as separate ghc-for-ghc package :) the core-ghc package should then contain only libraries that are dependent on GHC compiler internals (GHC.* part of base, stm and th - and nothing more!) moreover, i want to be able to upgrade even these libraries without upgrading compiler proper. or, to be exact, i may need to install newer versions of these libraries which contains new features and therefore not 100% compatible with libraries shipped at the moment when GHC 6.6.1 was released why this may be impossible? first, because existing libs and programs may rely on older interfaces. i think that Cabal should eventually solve this problem so that multiple version of any lib can be installed on computer (to be exact, on concrete GHC installation) and proper version of library selected for any project. but that's another discussion.. what is a 'base' library now? it is the library that implements common set of operations for latest versions of ghc, hugs and nhc. it contains low-level implementation for ghc, but relies on separate hugsbase package for hugs (the same for nhc, afaiu). so, first step is obvious - separate ghc-base library from the rest. hugsbase, ghc-base and nhc-base packages should provide common set of low-level operations, hiding from other libraries implementation details, differences between compilers, and differences between compiler versions. they should provide _incremental_ interfaces so that old code will continue to work with newer compilers. eventually compiler-specific code for stm and th should also go into these libraries but that is not the immediate goal then, a base library may be written against virtual Haskell compiler, which provides uniform set of low-level features while 'base' decorates these features with user-friendly interfaces even more interesting variant is to allow ghc-base and other compiler-specific base packages to export non-incremental interfaces and use 'base' solely to equalize all compilers to some common interface, providing emulation of all missing features (i think that such emulation will be compiler-independent that means that it's better to put it into compiler-independent package). then, _all_ other libs should rely on version of base package version instead of version of compiler they are use. so: ghc 6.2 ghc 6.2.2 ghc 6.4.3 hugs 2003 all supported in base 1.0 package which expose stable interface independent on compiler used. all other libraries relies on this interface and therefore works with any compiler whose support included in base 1.0. as ghc 6.6 rolls out, we add its support to 'base' library, rolling out base-1.0.1. and all libraries written against base 1.0, now will work with ghc 6.6, although they can ignore some features what was not included in base 1.0 API. at the same time, base-2.0 rolled out which includes new APIs (but don't omit old ones!), supporting new features of ghc 6.6. but base 2.0 continues to support existing compilers, providing emulation of new features for old compilers. those developers that need these new features upgrade their cabal files to require base 2.0. those users of old compilers that go to compile these apps download (automatically) and install base-2.0 lib so, i propose: - ghc-base/hugsbase/.. libs to implement _subset_ of common low-level API - base lib to equalize several compilers and compiler versions, providing _full_ common low-level API. when we need to include new API, we roll out new major version of base and work hard to support old compilers by providing some emulation of new feature. base lib versions should be independent on compiler versions and as much backward-compatible as possible - all other libs to just
Re[2]: Test Suite's Dependency on Quickcheck
Hello Brian, Wednesday, September 13, 2006, 10:17:10 AM, you wrote: Maybe we need to separate the packages into three groups: core, tests, and extras, where all the packages required by the test suite would get put into the tests group? or core, ghc-for-ghc and don't-matter? :) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Help with unregisterised build
Hello GHC users, I've attempted to build an installation of GHC which uses unregisterised libraries, but have not had much success. I am new to GHC's build system and would be grateful for some advice. I'm trying to build the 6.4.2 source distribution on an x86 linux machine, using GHC 6.4.2 (the Generic Linux with glibc2.3 version on the download page.) The target is the same machine. I've created a mk/build.mk file containing just the line: GhcUnregisterised = YES which, according to the comment in mk/config.mk, ought to build the unregisterised libraries that I'm after (and use them by default.) I run configure as follows: ./configure --prefix=$HOME/ghc_u and then simply make. After some time, the build fails with the following: ==fptools== make all -wr; in /mnt/raid/home/jeremyrw/src/src/ghc-6.4.2/libraries/base ../../ghc/compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude -#include HsBase.h -funbox-strict-fields -ignore-package base -O -Rghc-timing -fgenerics -fgenerics -split-objs-c GHC/Err.lhs-boot -o GHC/Err.o-boot -ohi GHC/Err. hi-boot ghc: 13862608 bytes, 4 GCs, 102828/102828 avg/max bytes residency (1 samples), 18M in use, 0.00 INIT (0.00 elapsed), 0.03 MUT (0.03 elapsed), 0.00 GC (0.02 elapsed) :ghc rm -f GHC/Base.o; if [ ! -d GHC/Base_split ]; then mkdir GHC/Base_split; else /usr/bin/find GHC/Base_split -name '*.o' -print | xargs rm -f __rm_food; fi; ../../ghc/compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude -#include HsBase.h -funbox-strict-fields -ignore-package base -O Rghc-timing -fgenerics -fgenerics -split-objs-c GHC/Base.lhs -o GHC/Base.o -ohi GHC/Base.hi /tmp/ghc4237.s: Assembler messages: /tmp/ghc4237.s:17: Error: symbol `__stg_split_marker' is already defined /tmp/ghc4237.s:29: Error: symbol `__stg_split_marker' is already defined /tmp/ghc4237.s:41: Error: symbol `__stg_split_marker' is already defined /tmp/ghc4237.s:53: Error: symbol `__stg_split_marker' is already defined This goes on for a while ... /tmp/ghc4237.s:16568: Error: symbol `__stg_split_marker' is already defined /tmp/ghc4237.s:16614: Error: symbol `__stg_split_marker' is already defined /tmp/ghc4237.s:16660: Error: symbol `__stg_split_marker' is already defined /tmp/ghc4237.s:16706: Error: symbol `__stg_split_marker' is already defined ghc: 124912780 bytes, 12 GCs, 808164/1513632 avg/max bytes residency (2 samples), 19M in use, 0.00 INIT (0.00 elapsed), 0.59 MUT (2.39 elapsed), 0.10 GC (0.09 elapsed) :ghc make[2]: *** [GHC/Base.o] Error 1 make[1]: *** [all] Error 1 make[1]: Leaving directory `/mnt/raid/home/jeremyrw/src/src/ghc-6.4.2/libraries' make: *** [build] Error 1 I've also tried with the following build.mk (I was guessing the -fvia-C might avoid the above assembler problem.): GhcUnregisterised = YES GhcLibHcOpts = -O -fvia-C but it fails in the same way. I'm not sure what to do at this point. Am I missing something in the build.mk? My ultimate goal is to link a Haskell object, which exports one of its functions via the FFI, with some other objects, into a single shared object. To do this I will need to compile everything with gcc's -fPIC flag, hence the need for unregisterised libraries. To go that extra step (to get relocatable GHC libraries), I'm guessing that I'll need to extend the GhcLibHcOpts line in build.mk with: -optc -fPIC. Will I need to do that for the run-time system as well? i.e. adding a line like: GhcRtsHcOpts = -fvia-C -optc '-fPIC' Is there likely to be anything else that needs to be tweaked? Has anybody had any success with this sort of thing before? Regards, Jeremy On Yahoo!7 Answers: 25 million answers and counting. Learn something new today http://www.yahoo7.com.au/answers ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Test Suite's Dependency on Quickcheck
On Wed, 2006-09-13 at 01:17 -0500, Brian Smith wrote: After further review, I can see that the test suite also requires 'network,' 'html,' and 'mtl' for all the tests to pass. Maybe we need to separate the packages into three groups: core, tests, and extras, where all the packages required by the test suite would get put into the tests group? I would suggest a better approach is to simply have the testsuite be more of an independent package and just accept that it depends on ghc and the other packages. This what we're doing in gentoo now, we have a 'pseudo' package ghc-testsuite that depends on ghc, mtl, quickcheck etc. (It's 'pseudo' in the sense that it doesn't install anything except the testsuite summary results). The testsuite has a few assumptions that it's located inside a configured ghc build tree. If this could be made simpler then this would seem a sensible approach. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
