Menu
▾
▴
hoc-devel — Developer discussion about HOC
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
(2) |
Oct
(5) |
Nov
|
Dec
|
| 2006 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2008 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(3) |
Aug
(18) |
Sep
(8) |
Oct
(5) |
Nov
(1) |
Dec
(14) |
| 2009 |
Jan
(9) |
Feb
(7) |
Mar
(6) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(23) |
Sep
(9) |
Oct
|
Nov
|
Dec
(1) |
| 2010 |
Jan
(2) |
Feb
(3) |
Mar
(1) |
Apr
|
May
|
Jun
(6) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
(1) |
Mar
(6) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: <cod...@go...> - 2009-01-02 14:05:29
|
Updates: Labels: Component-Build Comment #1 on issue 12 by james.c...@usma.edu: Can't build with cabal install http://code.google.com/p/hoc/issues/detail?id=12 This is the same problem I ran into while trying to fix Issue 10. The "quick fix", if possible, is to use ghc <6.10. A slightly less quick workaround is to remove the 'c-sources' line in the .cabal file and manually link HOC_cbits.o into the build product (both the .a and the .o). The primary cause is that the HOC_cbits.o object file is listed as a C source file, causing ghc 6.10 to complain loudly (stopping the build process) that there are no input files when 'ghc -c' is called for it. Earlier versions of ghc silently ignore it and report success. The deeper cause (the reason it's being done that way) is that it is a reasonably simple way of getting Cabal to accept an object file as an input to the build process. Just removing the offending line won't work unless we also cause it to be linked in to the build products (presumably in a post-build hook in the Setup file). If no-one else picks this up I'll get to it, but I don't know when that may be. I'm not much of a cabal wizard though, so if anyone has any pointers I'm happy to hear them. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2008-12-31 15:42:53
|
Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 12 by JeanPhilippe.bernardy: Can't build with cabal install http://code.google.com/p/hoc/issues/detail?id=12 $ cabal install ... Warning: the following files would be used as linker inputs, but linking is not being done: HOC_cbits.o ghc: no input files Usage: For basic information, try the `--help' option. cabal: Error: some packages failed to install: HOC-1.0 failed during the building phase. The exception was: exit: ExitFailure 1 $ cabal --version cabal-install version 0.6.0 using version 1.6.0.1 of the Cabal library $ uname -a Darwin Celebrian.local 9.5.0 Darwin Kernel Version 9.5.0: Wed Sep 3 11:29:43 PDT 2008; root:xnu-1228.7.58~1/RELEASE_I386 i386 -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2008-12-29 17:35:17
|
Updates: Status: Started Labels: Component-Build Comment #2 on issue 10 by james.c...@usma.edu: Build error: Ambiguous type variable in HOC.Exception http://code.google.com/p/hoc/issues/detail?id=10 I have fixed the ghc errors, but there is a cabal problem (described in more detail in the commit notes for r379) that I haven't yet figured out how to deal with. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2008-12-29 16:15:52
|
Status: Started Owner: james.c...@usma.edu Labels: Type-Enhancement Priority-Medium Usability New issue 11 by james.c...@usma.edu: Do not completely override retain/release http://code.google.com/p/hoc/issues/detail?id=11 NSManagedObject does some kind of magic with its retain/release which breaks when HOC overrides them. (The NSManagedObject documentation also specifically states that those methods "must not" be overridden). Unfortunately this is a relatively difficult thing to create a test case for, but "in the wild" what happens is the object gets prematurely deallocated, usually upon the first edit to a managed object after loading from a persistent store. I have a patch at home that fixes the problem by changing the behavior of HOC's retain/release implementations to use calls to [super retain], [super release], and [super retainCount], however I don't know whether this would be considered an unnecessary performance hit to do so in all cases. Should I push the change or just post a patch here for review? -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2008-12-29 15:48:43
|
Updates: Status: Fixed Comment #1 on issue 10 by james.c...@usma.edu: Build error: Ambiguous type variable in HOC.Exception http://code.google.com/p/hoc/issues/detail?id=10 Fixed in r378. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2008-12-18 01:50:08
|
Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 10 by brodie.rao: Build error: Ambiguous type variable in HOC.Exception http://code.google.com/p/hoc/issues/detail?id=10 $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.1 $ cd hoc # at r372 $ cabal install [...] [11 of 31] Compiling HOC.Exception ( HOC/HOC/Exception.hs, dist/build/HOC/Exception.o ) HOC/HOC/Exception.hs:33:12: Ambiguous type variable `a' in the constraint: `base:GHC.Exception.Exception a' arising from a use of `throwIO' at HOC/HOC/Exception.hs:33:12-22 Probable fix: add a type signature that fixes these type variable(s) cabal: Error: some packages failed to install: HOC-1.0 failed during the building phase. The exception was: exit: ExitFailure 1 -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2008-12-10 22:17:36
|
[hoc] james.c...@usma.edu commented on revision r376. Details are at http://code.google.com/p/hoc/source/detail?r=376 General Comment: I don't suppose anyone knows how to suppress that garbage svk added to the front of my log message? Respond to these comments at http://code.google.com/p/hoc/source/detail?r=376 -- You received this message because you starred this review, or because your project has directed all notifications to a mailing list that you subscribe to. You may adjust your review notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2008-12-09 23:27:06
|
Comment #4 on issue 5 by wolfgang...@gmx.net: Use Objective-C 2.0 runtime interface http://code.google.com/p/hoc/issues/detail?id=5 Thanks a lot! I hope I will get around to looking at this more closely next weekend. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2008-12-09 21:02:13
|
[hoc] james.c...@usma.edu commented on revision r368. Details are at http://code.google.com/p/hoc/source/detail?r=368 General Comment: Note that moving to this revision requires rebuilding bindings, because a change was made to the declareClass template-haskell function. Respond to these comments at http://code.google.com/p/hoc/source/detail?r=368 -- You received this message because you starred this review, or because your project has directed all notifications to a mailing list that you subscribe to. You may adjust your review notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2008-12-09 20:37:05
|
Updates: Status: Fixed Comment #3 on issue 5 by james.c...@usma.edu: Use Objective-C 2.0 runtime interface http://code.google.com/p/hoc/issues/detail?id=5 I am more or less satisfied with what I have in the objc2 branch. I do not have a GNUstep machine on which to test my changes (especially the changes to the build system). If someone could test it out, as well as review my modifications for any style or organization issues, I would appreciate it. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2008-12-09 20:32:09
|
Updates: Status: Fixed Comment #2 on issue 9 by james.c...@usma.edu: "super" does not chain properly on Mac OS 10.5.5 http://code.google.com/p/hoc/issues/detail?id=9 Fixed in r368. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2008-12-08 20:23:27
|
Updates: Status: Started Comment #2 on issue 5 by james.c...@usma.edu: Use Objective-C 2.0 runtime interface http://code.google.com/p/hoc/issues/detail?id=5 Woo hoo, I'm cocoa-binding away in my Xcode. The code is still a bit ugly, but as of r366 "branches/objc2" has working (for me at least) objective-C 2.0 class allocation and registration. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2008-12-08 20:04:23
|
Comment #1 on issue 9 by james.c...@usma.edu: "super" does not chain properly on Mac OS 10.5.5 http://code.google.com/p/hoc/issues/detail?id=9 Based on what I see in Super.hs I expect this to happen on all runtimes, unless I'm missing some kind of magic. The problem is especially noticeable though when using cocoa bindings, because it seems that the cocoa binding subsystem adds a subclass that then poses as the original class - so "super" becomes a guaranteed infinite loop. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2008-12-08 19:51:19
|
Status: New Owner: james.c...@usma.edu Labels: Type-Defect Priority-Medium New issue 9 by james.c...@usma.edu: "super" does not chain properly on Mac OS 10.5.5 http://code.google.com/p/hoc/issues/detail?id=9 Steps to reproduce the problem: 1. Define a class with a method that calls super 2. Subclass that class 3. Call the method that calls super on the subclass - What I expect is that call to super should dispatch to the implementation from the class above the class implementing that version of the method. - What I see is that the call goes to the superclass of the implementation of the object, triggering an infinite loop of calls to that same implementation until the stack overflows. The following code exhibits the behavior I am seeing: {-# LANGUAGE TemplateHaskell, TypeSynonymInstances, FlexibleInstances, MultiParamTypeClasses, DeriveDataTypeable #-} module Main where import HOC import Foundation (NSObject, NSObjectClass, alloc, init) import Prelude hiding (init) $(declareSelector "sayHi" [t| IO () |]) $(declareClass "Hello" "NSObject") $(exportClass "Hello" "hello_" [ InstanceMethod 'sayHi ]) hello_sayHi self = do putStrLn "hi!" $(declareClass "Howdy" "Hello") $(exportClass "Howdy" "howdy_" [ InstanceMethod 'sayHi ]) howdy_sayHi self = do putStrLn "About to say hi:" super self # sayHi $(declareClass "Antisocial" "Howdy") $(exportClass "Antisocial" "" []) instance Has_sayHi (Hello a) main = do initializeClass_Hello initializeClass_Howdy initializeClass_Antisocial me <- _Antisocial # alloc >>= init me # sayHi -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2008-12-05 16:37:30
|
Comment #1 on issue 5 by james.c...@usma.edu: Use Objective-C 2.0 runtime interface http://code.google.com/p/hoc/issues/detail?id=5 I am interested in implementing at least a part of this in support of work I am doing. Specifically, I would like to be able to use "Cocoa Bindings" with Haskell- implemented subclasses of NSManagedObject and it appears to me that a necessary first step toward that working will be "proper" allocation and construction of the classes using the designated runtime functions. I have dug around a bit in the code to get my bearings, and I would like to do the following: - Refactor all "cbits" usage of structs objc_ivar, objc_ivar_list, objc_method, and obcj_method_list outside of newClass.m to a new set of structs named as hoc_ivar, etc. Additionally, I would like to include size and alignment information in the hoc_ivar struct in place of the offset currently used in objc_ivar. - Refactor all Haskell code's usage of IvarList to lists of a new opaque type Ivar, including wrapping HOC.NewClass.newClass to something that will marshall [Ivar] to struct hoc_ivar_list before calling the "cbits" newClass. - Change the 'instance size' parameter from newClass() in newClass.h/m to be an "extra bytes" parameter (or eliminate it entirely based on the assumption that it should always be zero). When dealing with the old runtime or the GNUStep runtime, the appropriate size would be calculated from the ivar list (plus the extra-bytes parameter). If the parameter is eliminated entirely, a flag on the ivar structure could be added indicating whether to add the ivar as an old-style "indexed" ivar or a new-style "managed" one, thus giving the flexibility to still provide the old style ivars if necessary for some reason. - Implement a build flag for "objective C 2.0 mode" - When in that mode, use the new objective C 2.0 runtime stuff to implement newClass. If anyone is currently working on this or has any input about an appropriate strategy or ways the strategy outlined here should be modified, please let me know. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2008-11-15 02:17:27
|
Issue 7: HOC build errors http://code.google.com/p/hoc/issues/detail?id=7 Comment #1 by bickfordb: +1 -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2008-10-29 11:10:10
|
Issue 8: Fail to parse 64bit compatible headers http://code.google.com/p/hoc/issues/detail?id=8 Comment #1 by grddev: Patched the specific problem in r345. A more long-term solution would be desirable, though. Issue attribute updates: Status: Fixed -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2008-10-29 11:06:11
|
Issue 8: Fail to parse 64bit compatible headers http://code.google.com/p/hoc/issues/detail?id=8 New issue report by grddev: Issue initially reported here: http://www.haskell.org/pipermail/haskell-cafe/2008-October/049907.html What steps will reproduce the problem? 1. Update to 10.5.5 2. cd HOC 3. cabal install --user 4. (cd Bindings; bash make-bindings-macos.sh --user) What is the expected output? What do you see instead? Building and installing HOC-Foundation fails, because the headers are now 64bit-compatible, which means that NSPoint is defined in terms of CGFloat instead of float, and since CGFloat is not recognized, NSPoint is zapped. Issue attributes: Status: Accepted Owner: grddev Labels: Type-Defect Priority-Medium -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2008-10-28 19:51:02
|
Issue 7: HOC build errors http://code.google.com/p/hoc/issues/detail?id=7 New issue report by rzilibow...@yahoo.com.au: What steps will reproduce the problem? 1. check out hoc using svn 2. cd to the directory hoc 3. run autogen.sh; configure; make Below is the output from make that includes the errors. I'm trying to build HOC on Mac OS 10.5 on an Intel iMac using GHC 6.8.3. for dir in HOC_cbits HOC InterfaceGenerator InterfaceGenerator2 Bindings Foundation AppKit Tools docs ; do (cd $dir; echo "In directory $dir"; make all) done In directory HOC_cbits make[1]: Nothing to be done for `all'. In directory HOC make[1]: Nothing to be done for `all'. In directory InterfaceGenerator make[1]: Nothing to be done for `all'. In directory InterfaceGenerator2 mkdir -p build ghc --make Main.hs \ -odir build -hidir build \ -package-conf ../inplace.conf \ -o hoc-ifgen Headers.hs:26:7: Could not find module `Text.Parsec': Use -v to see a list of the files searched for. make[1]: *** [hoc-ifgen] Error 1 In directory Bindings make[1]: Nothing to be done for `all'. In directory Foundation ln -sf ../Bindings/ifgen-output/Foundation.hs . ln -sf ../Bindings/ifgen-output/Foundation . test ! -d ../Bindings/ifgen-output/GNUstepBase || \ ln -sf ../Bindings/ifgen-output/GNUstepBase . test ! -r ../Bindings/ifgen-output/GNUstepBase.hs || \ ln -sf ../Bindings/ifgen-output/GNUstepBase.hs . mkdir -p build/objects mkdir -p build/imports ghc --make Foundation.hs \ -O -fasm \ -odir build/objects \ -package-name Foundation \ -hidir build/imports \ -package-conf ../inplace.conf \ -fglasgow-exts -fth\ -package unix \ [ 1 of 221] Compiling Foundation.FoundationErrors.Forward ( Foundation/FoundationErrors/Forward.hs, build/objects/Foundation/FoundationErrors/Forward.o ) Loading package base ... linking ... done. Loading package old-locale-1.0.0.0 ... linking ... done. Loading package old-time-1.0.0.0 ... linking ... done. Loading package filepath-1.1.0.0 ... linking ... done. Loading package directory-1.0.0.1 ... linking ... done. Loading package unix-2.3.0.1 ... linking ... done. Loading package pretty-1.0.0.0 ... linking ... done. Loading package array-0.1.0.0 ... linking ... done. Loading package packedstring-0.1.0.0 ... linking ... done. Loading package containers-0.1.0.2 ... linking ... done. Loading package template-haskell ... linking ... done. ghc-6.8.3: ../HOC/HOC.o: unknown symbol `___stginit_mtlzm1zi1zi0zi1_ControlziMonadziState_' Loading package HOC ... linking ... ghc-6.8.3: unable to load package `HOC' make[1]: *** [ghcmake.build-stamp] Error 1 In directory AppKit ln -sf ../Bindings/ifgen-output/Cocoa.hs . ln -sf ../Bindings/ifgen-output/AppKit.hs . ln -sf ../Bindings/ifgen-output/AppKit . test ! -d ../Bindings/ifgen-output/GNUstepGUI || \ ln -sf ../Bindings/ifgen-output/GNUstepGUI . test ! -r ../Bindings/ifgen-output/GNUstepGUI.hs || \ ln -sf ../Bindings/ifgen-output/GNUstepGUI.hs . mkdir -p build/objects mkdir -p build/imports ghc --make AppKit.hs \ -O -fasm \ -package-name AppKit \ -odir build/objects \ -hidir build/imports \ -package-conf ../inplace.conf \ -fglasgow-exts -fth \ -package unix \ AppKit/NSTokenField.hs:122:7: Could not find module `Foundation.NSObject.Forward': Use -v to see a list of the files searched for. make[1]: *** [ghcmake.build-stamp] Error 1 In directory Tools mkdir -p build/hocwrap ghc --make HOCWrap.hs \ -fglasgow-exts \ -o hocwrap \ -odir build/hocwrap -hidir build/hocwrap \ -package-conf ../inplace.conf HOCWrap.hs:24:7: Could not find module `Foundation.NSObject': Use -v to see a list of the files searched for. make[1]: *** [hocwrap] Error 1 In directory docs make[1]: Nothing to be done for `all'. Issue attributes: Status: New Owner: ---- Labels: Type-Defect Priority-Medium -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2008-10-19 19:41:22
|
Issue 6: Update old Sourceforge project pages to direct users to newer Google Code project page. http://code.google.com/p/hoc/issues/detail?id=6 Comment #1 by wolfgang...@gmx.net: Added a notice to the sourceforge page. Sorry about the confusion. Issue attribute updates: Status: Fixed -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2008-10-11 14:46:40
|
Issue 6: Update old Sourceforge project pages to direct users to newer Google Code project page. http://code.google.com/p/hoc/issues/detail?id=6 New issue report by gbmvdd: What steps will reproduce the problem? 1. Search for something like [hoc objective-c haskell]. 2. Follow the obvious link from the results page. 3. Read about HOC's development status, and download it. Expected: Up-to-date project information and code. Actual: Out-of-date, Sourceforge-based project information and code. It would be nice to alert visitors to the Sourceforge pages to the fact that they should be somewhere else, using a large obvious notice of some sort. Issue attributes: Status: New Owner: ---- Labels: Type-Defect Priority-Medium -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2008-09-10 22:40:57
|
Issue 5: Use Objective-C 2.0 runtime interface http://code.google.com/p/hoc/issues/detail?id=5 New issue report by wolfgang...@gmx.net: ... while retaining compatibility with the old interface. The new interface is quite convenient and easy to use, so it shouldn't be too hard. It should be done sooner or later, because the old interface is already officially deprecated. It is also a prerequisite for 64-bit support. Issue attributes: Status: New Owner: wolfgang...@gmx.net Labels: Type-Enhancement Priority-Low Component-Core -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2008-09-10 22:36:55
|
Issue 4: Integrate with Apple's garbage collector http://code.google.com/p/hoc/issues/detail?id=4 New issue report by wolfgang...@gmx.net: Sooner or later someone will want to link with code that has been written to require ObjC garbage collection. We had better be ready. Issue attributes: Status: Accepted Owner: wolfgang...@gmx.net Labels: Type-Enhancement Priority-Medium Component-Core OpSys-OSX -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2008-09-10 22:32:54
|
Issue 3: Retire old interface generator and autoconf build system http://code.google.com/p/hoc/issues/detail?id=3 Comment #1 by wolfgang...@gmx.net: (No comment was entered for this change.) Issue attribute updates: Status: New Labels: Component-Build Component-Ifgen -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2008-09-10 22:15:05
|
Issue 3: Retire old interface generator and autoconf build system http://code.google.com/p/hoc/issues/detail?id=3 New issue report by wolfgang...@gmx.net: Currently, there are two separate build systems and two separate implementations of the interface generator in the tree. The old interface generator is less powerful and considerably less maintainable, and the old build system is, well, autoconf-based. We should make sure that the new, Cabal-based build system does everything we want and then retire the old one. Issue attributes: Status: Accepted Owner: wolfgang...@gmx.net Labels: Type-Enhancement Priority-Medium Milestone-Release1.0 -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
