
I'm having a shot at packaging my revision of the HaXml library using Cabal, using [1] as reference: [1] http://www.haskell.org/libraryInfrastructure/proposal/index.html I'm basically stuck at the point of bootstrapping Cabal into my system (see point 9 towards the end, below). I'm proceeding on the basis of using Windows and Hugs. I *could* use GHC, but for non-Haskellers I think Hugs represents the easiest path of entry into using Haskell software, so I'd like to persist with that. ... There are some random notes jotted down as I progress. 1. Section 1.2 example of Setup.description has field Exposed-modules, but section 4.1 described field "Modules". Which is correct? [Later, I see both are defined. The relationship could usefully be clarified sooner.] 2. At this stage, it's not clear if I should include full hierarchical package names, or just list packages relative to the working directory. I'm assuming the latter. 3. I've collected my list of exported modules by copying imports statements from the unit test program. 4. Copyright: this isn't a pure Cabal question: how does one indicate the copyright of a package that have been heavily extended like my version of HaXml. The original Copyright should be respected, but there's a lot of new code too. Can I use multiple Copyright fields? 5. The Setup.description file doesn't appear to have provision for a free-form description of the package. Suggest 'Description:', e.g.: [[ Description: This HaXml-I package is a derivative of the HaXml package maintained by Malcolm Wallace, with a number of enhancements: - support for XML namespaces, xml:lang and xml:base - passes a significant number of W3C conformance tests - support for Unicode UTF-8 and UTF-16 character encodings - redesigned external entity support, including support for HTTP access to external entities. ]] (A Wiki-like format would be handy here; now wasn't someone working on that?) 6. Description file comments: is the '--' required to start at column 1? I think this should be 'yes', given the leading-space sensitive nature of the header field format. 7. I'm uneasy about the prohibition against completely empty lines in the Setup.description file. I guess this is following RFC2822/MIME, right? I see a mismatch here with my suggested "Description:" field, and am not sure which should hold sway. 8. Setup.lhs. Following the example in section 1.2, is it intended that Hugs will always used to run the installation. I.e. Hugs must be installed? I like the runhaskell idea better. I guess we just need to work through this to figure out how things work in the various environments. For my Windows system, for the time being I've taken the simple expedient of placing a file "RunHaskell.bat" in a directory on the Path: [[ C:\DEV\Hugs98\runhugs-20040109.exe %1 %2 %3 %4 %5 %6 %7 %8 %9 ]] (There are probably better/neater ways to achieve this goal, but I like using batch/script files in this way, as it makes the actual location of the actual program files used very transparent.) 9. At this point, I get stuck. How am I supposed to bootstrap Cabal? I tried unzipping the Cabal distribution, switching to the Cabal directory, then: [[ K:\>cd K:\DEVKIT\Haskell\Cabal\cabal K:\DEVKIT\Haskell\Cabal\cabal>runhaskell Setup.lhs K:\DEVKIT\Haskell\Cabal\cabal>C:\DEV\Hugs98\runhugs-20040109.exe Setup.lhs runhugs: Error occurred Reading file "Setup.lhs": Reading file ".\Distribution\Simple.hs": Parsing ERROR ".\Distribution\Simple.hs":52 - Syntax error in module definition (unexpec ted selector "#ifdef") ]] There seems to be a kind of "Catch-22" problem here: how to get Cabal installed without Cabal first being installed. 10. I'll repeat here a comment made on the list. I think there should be an option in the Setup.description file to specify what file extensions are to be passed through the hscpp (or whatever) program. 11. If Cabal does not ship with hscpp for performing all preprocessing, I'd suggest having a point of indirection (like "runhaskell") so that systems without cpp but with hscpp can be set up to invoke this. ... I think that's as much as I can usefully do at this stage. If anyone has any further suggestions I'm willing to try them out. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

Hi Graham. Thanks for your comments!
Graham Klyne
I'm having a shot at packaging my revision of the HaXml library using Cabal, using [1] as reference:
[1] http://www.haskell.org/libraryInfrastructure/proposal/index.html
I'm basically stuck at the point of bootstrapping Cabal into my system (see point 9 towards the end, below). I'm proceeding on the basis of using Windows and Hugs. I *could* use GHC, but for non-Haskellers I think Hugs represents the easiest path of entry into using Haskell software, so I'd like to persist with that.
I haven't worked much with the Hugs code; I'm mostly focusing on an end-to-end solution with GHC first, then branching out to other implementations, if no one beats me to them. If you want to use Hugs, you'll have to help contribute some code :)
1. Section 1.2 example of Setup.description has field Exposed-modules, but section 4.1 described field "Modules". Which is correct? [Later, I see both are defined. The relationship could usefully be clarified sooner.]
Eventually, we want to mostly use Exposed-modules and Main-modules (or whatever), then compute the dependencies to the rest of the modules to include. Modules will probably stay around as a backup. I made a note to clarify that in the docs.
2. At this stage, it's not clear if I should include full hierarchical package names, or just list packages relative to the working directory. I'm assuming the latter.
The full hierarchical package name, relative to the hssource directory. There are a few examples shipped with the source for what it's worth. Look under "test".
4. Copyright: this isn't a pure Cabal question: how does one indicate the copyright of a package that have been heavily extended like my version of HaXml. The original Copyright should be respected, but there's a lot of new code too. Can I use multiple Copyright fields?
Copyright is a free text string, so you can put whatever you want here, but there's only one field. For license, if yours isn't on the list, then you use (OtherLicense FilePath) to indicate the location of a license file.
5. The Setup.description file doesn't appear to have provision for a free-form description of the package. Suggest 'Description:', e.g.:
Yeah, this should be added, along with a few other fields that are needed for the "Hackage" infrastructure. (snip)
(A Wiki-like format would be handy here; now wasn't someone working on that?)
Not that I can recall.
6. Description file comments: is the '--' required to start at column 1? I think this should be 'yes', given the leading-space sensitive nature of the header field format.
Yeah, I think so. I'll make a note to double-check.
7. I'm uneasy about the prohibition against completely empty lines in the Setup.description file. I guess this is following RFC2822/MIME, right? I see a mismatch here with my suggested "Description:" field, and am not sure which should hold sway.
I think the solution is to use a " ." to indicate an empty line in the description.
8. Setup.lhs. Following the example in section 1.2, is it intended that Hugs will always used to run the installation.
Nope. For now, the solution is "Execute Setup however you can" in the future, once someone writes it (hint, hint), we'll use the "runhaskell" tool which might choose the default compiler / interpreter.
For my Windows system, for the time being I've taken the simple expedient of placing a file "RunHaskell.bat" in a directory on the Path: [[ C:\DEV\Hugs98\runhugs-20040109.exe %1 %2 %3 %4 %5 %6 %7 %8 %9 ]] (There are probably better/neater ways to achieve this goal, but I like using batch/script files in this way, as it makes the actual location of the actual program files used very transparent.)
I don't know anything about widows batch files, but it would be great if someone knowledgeable would create the windows version of runhaskell.
9. At this point, I get stuck. How am I supposed to bootstrap Cabal?
Did you read the README? Cabal comes with a bootstrap makefile. In the future, it'll hopefully be distributed with the compilers to make this easier. (snip)
runhugs: Error occurred Reading file "Setup.lhs": Reading file ".\Distribution\Simple.hs": Parsing ERROR ".\Distribution\Simple.hs":52 - Syntax error in module definition (unexpec ted selector "#ifdef") ]]
You're going to have some trouble using Hugs here, since the makefile doesn't have any hugs target and so there's no preprocessing step. Theoretically, most if not all of the code is portable, we just need the makefile rules to do the bootstrapping and such. It'll be easier once we figure out how to do preprocessing in cabal itself, so I've been a little lazy here.
There seems to be a kind of "Catch-22" problem here: how to get Cabal installed without Cabal first being installed.
Yep. See above.
10. I'll repeat here a comment made on the list. I think there should be an option in the Setup.description file to specify what file extensions are to be passed through the hscpp (or whatever) program.
I'm not sure I understand this, I'll have to read back over the list.
11. If Cabal does not ship with hscpp for performing all preprocessing, I'd suggest having a point of indirection (like "runhaskell") so that systems without cpp but with hscpp can be set up to invoke this.
In the short-term (at least), I think I'll probably include hscpp with cabal
I think that's as much as I can usefully do at this stage. If anyone has any further suggestions I'm willing to try them out.
So is ghc a problem for you? If so, you'll have to hack the makefiles to get it working with hugs (and send me the patch!!) If not, then just switch to ghc, read the README, and you should be set. Please let me know how things are working for Windows, send me any patches you make (preferably with darcs, which is really easy!) Hopefully that's enough to get you unstuck. peace, isaac

At 11:23 22/10/04 -0400, Isaac Jones wrote:
Hi Graham. Thanks for your comments!
Graham Klyne
writes: I'm having a shot at packaging my revision of the HaXml library using Cabal, using [1] as reference:
[1] http://www.haskell.org/libraryInfrastructure/proposal/index.html
I'm basically stuck at the point of bootstrapping Cabal into my system (see point 9 towards the end, below). I'm proceeding on the basis of using Windows and Hugs. I *could* use GHC, but for non-Haskellers I think Hugs represents the easiest path of entry into using Haskell software, so I'd like to persist with that.
I haven't worked much with the Hugs code; I'm mostly focusing on an end-to-end solution with GHC first, then branching out to other implementations, if no one beats me to them. If you want to use Hugs, you'll have to help contribute some code :)
I'll do what I can, and my supplementary questions will focus on that... [...]
9. At this point, I get stuck. How am I supposed to bootstrap Cabal?
Did you read the README? Cabal comes with a bootstrap makefile. In the future, it'll hopefully be distributed with the compilers to make this easier.
Er, yes, but I gave up as soon as I saw "makefile". Any approach that depends on make is not portable top a bare Window system. Hmmm... unless the makefile is compatible with hsmake?
You're going to have some trouble using Hugs here, since the makefile doesn't have any hugs target and so there's no preprocessing step. Theoretically, most if not all of the code is portable, we just need the makefile rules to do the bootstrapping and such. It'll be easier once we figure out how to do preprocessing in cabal itself, so I've been a little lazy here.
OK, for the time being, I suggest isolating the non-portable code and creating a windows-specific version. If you can point me to the relevant modules, I'll look into creating windows-specific versions and a batch file to replace them in the main source directory and compile/run them them. There's a technique something like this used for the Hugs distribution, IIRC. ...
10. I'll repeat here a comment made on the list. I think there should be an option in the Setup.description file to specify what file extensions are to be passed through the hscpp (or whatever) program.
I'm not sure I understand this, I'll have to read back over the list.
Maybe better I explain in a little more detail... This was in relation to the discussion of file name conventions for preprocessing and literate Haskell, etc. A number of different naming conventions were suggested. My view is that rather than forcing everyone to use the same naming conventions for various files, the Setup.description file could specify what filenames would be subject to special processing; e.g.: Preprocess: (.cpphs,.hs),(.cpplhs,.lhs) A default value being selected to match common usage. A similar directive might be used for literate source processing.
11. If Cabal does not ship with hscpp for performing all preprocessing, I'd suggest having a point of indirection (like "runhaskell") so that systems without cpp but with hscpp can be set up to invoke this.
In the short-term (at least), I think I'll probably include hscpp with cabal
I have successfully run hscpp under Windows/Hugs, but I think may have needed to make a couple of small changes. I think that making it easy to switch cpp implementation will make it easier to get Cabal up and running on various platforms. Then (I believe) it will be easier to make such operation appear more seamless.
I think that's as much as I can usefully do at this stage. If anyone has any further suggestions I'm willing to try them out.
So is ghc a problem for you? If so, you'll have to hack the makefiles to get it working with hugs (and send me the patch!!) If not, then just switch to ghc, read the README, and you should be set. Please let me know how things are working for Windows, send me any patches you make (preferably with darcs, which is really easy!)
It's not GHC that's the main problem, its the dependency on makefiles. But if I can use hscpp, that's less of a problem. ... Summary: I think the next step is this: if you can point me at the non-portable modules in Cabal, I can try and figure out what it takes to run them under Windows, and feed the details back to you. Also, maybe, if you can point me to the code that invokes make, I'll see if I can figure a way to add a revectoring point there. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

Hi Graham. In brief...
Graham Klyne
It's not GHC that's the main problem, its the dependency on makefiles. But if I can use hscpp, that's less of a problem.
No, it's the dependency on GHC's ability to CPP. I don't know if you can use hscpp, I haven't tried.
Summary: I think the next step is this: if you can point me at the non-portable modules in Cabal, I can try and figure out what it takes to run them under Windows, and feed the details back to you.
AFAIK, there aren't any non-portable modules, after you've cpp'd them. If there are, I'd like to know about it. Just look at the makefile calls to ghc, I think it's pretty straightforward: mkdir -p dist/tmp ghc --make -Wall -odir dist/tmp -hidir dist/tmp Setup -o setup Then you can use ./setup configure, build, install, etc.
Also, maybe, if you can point me to the code that invokes make, I'll see if I can figure a way to add a revectoring point there.
None of the Distribution.Simple invokes make. peace, isaac

--- Isaac Jones
(snip)
runhugs: Error occurred Reading file "Setup.lhs": Reading file ".\Distribution\Simple.hs": Parsing ERROR ".\Distribution\Simple.hs":52 - Syntax error in module definition (unexpec ted selector "#ifdef") ]]
You're going to have some trouble using Hugs here, since the makefile doesn't have any hugs target and so there's no preprocessing step. Theoretically, most if not all of the code is portable, we just need the makefile rules to do the bootstrapping and such. It'll be easier once we figure out how to do preprocessing in cabal itself, so I've been a little lazy here.
One way to make Cabal really portable is to move the entire platform specific code out of it. One example is Distribution.Simple.GHCPackageConfig.localPackageConfig function, which uses HOME environment variable to determine the user's home directory, but this doesn't work under Windows. The CVS System.Directory module already provides the getAppUserDataDirectory function which is more suitable (and portable) in this case. Another example is Distribution.Simple.Utils.findBinary. Recently I had updated it and now it is portable but now I see that a similar function is used in runghc tool but in its non portable version. If we move this to the standard libraries then we will be able to use it in both cases. Most of the other #ifdef-s are related to the filepath handling. It will be great benefit if we isolate it in a separate library. I already use the filepath routines in VSHaskell. You can see that a similar functions are used in haddock, happy and alex tools. Maybe if we agree on this it is not too late to add it before the next GHC release. Cheers, Krasimir __________________________________ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com
participants (3)
-
Graham Klyne
-
Isaac Jones
-
Krasimir Angelov