- Libraries - Haskell.org

RE: Default prefix for Cabal on Windows
by Simon Marlow 21 Jun '05

21 Jun '05

On 17 June 2005 17:19, Ross Paterson wrote: > On Thu, Jun 16, 2005 at 04:46:18PM +0100, Simon Marlow wrote: >>> Simon Marlow wrote: >>> >>>> Ok, so $(ProgramFiles) is determined by the registry. Taking into >>>> account comments so far, I think we have: >>>> >>>> prefix = $(ProgramFiles)\Haskell\$(PackageName)-$(Version) >>>> libdir = $(prefix)\$(Compiler)-$(Version) >>>> bindir = $(prefix)\bin >>>> >>>> these are only defaults - users & packagers are free to change >>>> them. >> >> Slight modification after Brian's comments: if the package is an >> executable, then >> >> prefix = $(ProgramFiles)\$(PackageName)-$(Version) >> >> (i.e. only libraries on under $(ProgramFiles)\Haskell). > > The default value of $(prefix) under Unix recently silently changed > from /usr/local to /usr/local/$(Compiler)-$(Version). I'm not sure > that's the right thing: it's incompatible with the FHS and with > autoconf, and puts executables in a place that's not on my path. I've fixed that, and made the changes above. However, I think $(libdir) and $(bindir) should be configurable as options to ./setup configure (weren't we going to do that at one stage?). The story is now: On Windows, prefix | is_excutable = $(ProgramFiles)\$(PackageId) | is_library = $(ProgramFiles)\Haskell\$(PackageId) libdir = $(prefix)\$(CompilerId) bindir = $(prefix)\bin On Unix, prefix = "/usr/local" libdir = $(prefix)/$(PackageId)/$(CompilerId) bindir = $(prefix)/bin This is ok for the default prefix, but not great if you want to set prefix to /opt/pkg-1.0, for example - that's why we need to be able to set libdir independently. Cheers, Simon

2 1

Re: [Haskell-cafe] CGI module almost useless
by Sven Panne 18 Jun '05

18 Jun '05

[ Moving this thread slowly to the libraries list... ] Bjorn Bringert wrote: > John Goerzen wrote: > >> My apologies if this sounds like a bit of a rant; I know people put good >> effort into this, but.... >> >> The Network.CGI module in fptools (and GHC) is not very useful. I think >> that it should be removed or re-tooled. Here are the main problems with >> it: >> >> 1. It does not permit custom generation of output headers. Thus the CGI >> script cannot do things like set cookies, manage HTTP auth, etc. >> >> 2. It does not permit generation of anything other than text/html >> documents. Many CGI scripts are used to manage other types of >> documents. Notably this makes it incompatible with serving up even >> basic things like stylesheets and JPEGs. >> >> 3. It does not permit the use of any custom design to serve up HTML, >> forcing *everything* to go through Text.Html. This makes it impossible >> to do things like serving up HTML files from disk. >> >> 4. There is documentation in the code, but it is as comments only, and >> doesn't show up in the Haddock-generated GHC library reference. (Should >> be an easy fix) >> >> 5. It does not appear to support file uploads in any sane fashion >> >> Is there a better CGI module out there somewhere that I'm missing, or >> should I just set about writing my own? > > > I wrote this module (based on the Network.CGI code) a while ago: > > http://www.dtek.chalmers.se/~d00bring/darcs/blob/lib/Network/SimpleCGI.hs > > I don't remember what it does really, but I think it solves issues 1,2,3 > and some of 4. Although (among other people) I did some hacking in this module in the remote past, I don't have the time and energy to maintain and/or extend this module anymore. It would be really great if somebody more actively working in this area could take the spec lead here and push the development via discussions here on this library list. John? Björn? A few general design thoughts: * To keep people's mind sane, backwards compatibility with the existing Network.CGI would be a very worthy goal. * Don't use any Haskell language extension available. :-) Currently the module can be used e.g. by Hugs in H98 mode, and keeping it that way would again be something very desirable. Cheers, S.

5 6

RE: Default prefix for Cabal on Windows
by Simon Marlow 17 Jun '05

17 Jun '05

On 16 June 2005 16:23, Daan Leijen wrote: > Simon Marlow wrote: > >> Ok, so $(ProgramFiles) is determined by the registry. Taking into >> account comments so far, I think we have: >> >> prefix = $(ProgramFiles)\Haskell\$(PackageName)-$(Version) >> libdir = $(prefix)\$(Compiler)-$(Version) >> bindir = $(prefix)\bin >> >> these are only defaults - users & packagers are free to change them. >> >> Sound reasonable? > > Sounds fine to me. Slight modification after Brian's comments: if the package is an executable, then prefix = $(ProgramFiles)\$(PackageName)-$(Version) (i.e. only libraries on under $(ProgramFiles)\Haskell). Cheers, Simon

2 1

RE: Cabal help please
by Simon Marlow 17 Jun '05

17 Jun '05

On 16 June 2005 18:12, Adrian Hey wrote: > On Thursday 16 Jun 2005 4:48 pm, Isaac Jones wrote: >> "Simon Marlow" <simonmar(a)microsoft.com> writes: >>> On 16 June 2005 15:36, Adrian Hey wrote: >>>> Hello, >>>> >>>> I'm just getting around to tidying up the AVL library and releasing >>>> a new version and, of course thinking about Cabalising it too. But >>>> I'm finding difficult to figure out how to do this from the >>>> Cabal docs and Distribution library haddock. >>>> >>>> Anyway, what I want to do is.. >>>> Run cpphs on all the sources >>>> Compile the results using -split-objs (for ghc at least). >>> >>> Cabal doesn't support -split-objs at the moment. To do this you'll >>> need to write your own Makefile and hook it up to Cabal (possible, >>> but a bit fiddly I believe). >> >> Can someone outline what cabal needs to do to support this? > > I can't answer your question, but I can say using split objs is a > bit weird if you're not familiar with how ghc does it (dunno > if you are or not). The split objects don't seem to go in the > same directory as the main object (in this case a dummy object) > would go (according to hierarchical name). Instead they seem to > get placed in the root object directory $(OBJDIR). -split-objs is a bit weird, and I don't think it currently works with --make. So I think the best route is for us to fix GHC first, and then let you know what the (hopefully minimal) changes to Cabal should be. Cheers, Simon

1 0

Re: Default prefix for Cabal on Windows
by Brian Smith 17 Jun '05

17 Jun '05

* The "Program Files" folder usually has at least one space in its path, which could cause a lot of problems for Unix-centric software. For this reason alone, I always install anything that isn't Windows-specific into "c:\software" instead of "C:\Program Files." If the default prefix is going to be "Program Files" then there should be a note in the Cabal documentation that the application should expect to be installed into a directory with spaces in the path. * Even if a program is written in Haskell and is built with Cabal, I imagine that people who write Windows Haskell software for non-developers will not expect users to install the software via Cabal. Instead, they will provide an MSI with a GUI installer. That means that, for the most part, the only users of Cabal on Windows will be programmers. So, I think that the Cabal experience on Windows should be optimized for us. In particular, if I run "runghc Setup.hs install" when I am using MSYS Bash, I want the package to install into "/usr/local/" just like it would on Unix. * I don't think it makes sense for executable packages to have "Haskell" in their prefix unless they are explicitly "for Haskell." For example, Darcs isn't a Haskell tool; it is a versioning tool that happens to be implemented in Haskell, so it wouldn't make sense for it to be installed into "C:\Program Files\Haskell\Darcs-1.0," just like we wouldn't want it installed into "C:\Prgoram Files\C#\Darcs-1.0" if it was written in C#. Conversely, library packages are presumable Haskell-specific and so it makes sense for them to have "Haskell" in their prefix. Just my 2 cents. - Brian - Brian [1] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pl… [2] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html… - Brian or > > 2) C:\Haskell\<package-name>-<version> > > where "Haskell" could also be "Packages" I guess. > > -- Daan Leijen > > Brian Smith wrote: > > On 6/15/05, *Simon Marlow* <simonmar(a)microsoft.com > > <mailto:simonmar@microsoft.com >> wrote: > > > > On 15 June 2005 05:49, Brian Smith wrote: > > > > > The documentation states in Section 3.1 that the default value of > > > "prefix" is "/usr/local" on Unix. However, it doesn't specify > > what the > > > prefix is on Windows. I found that the default value for prefix is: > > > C:\Program > > > Files\<package-name>\<compiler-name>-<compiler-version>. For example, > > > version 1.0 of a package named "Foo" compiled with GHC > > > 6.5 would have a default prefix of: > > > C:\Program Files\Foo\ghc-6.5 > > > > > > The compiler version is there to avoid conflicts in the case when you > > have multiple versions of GHC installed and the package is installed for > > each one. However, I don't think we currently include the compiler & > > version in the default $(libdir) on Unix, so whatever we do we should do > > > it consistently. > > > > > > Okay, that makes more sense to me. However, I think that executables > > should go in "C:\Program Files\<package-name>-<package-version>\bin," > > not <C:\Program > > Files\<package-name>\<compiler-name>-<compiler-version>\bin" as they do > > currently. > > > > - Brian > > > > > > > > ------------------------------------------------------------------------ > > > > > _______________________________________________ > > Libraries mailing list > > Libraries(a)haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > >

3 2

RE: Cabal help please
by Simon Marlow 16 Jun '05

16 Jun '05

On 16 June 2005 15:36, Adrian Hey wrote: > Hello, > > I'm just getting around to tidying up the AVL library and releasing > a new version and, of course thinking about Cabalising it too. But > I'm finding difficult to figure out how to do this from the > Cabal docs and Distribution library haddock. > > Anyway, what I want to do is.. > Run cpphs on all the sources > Compile the results using -split-objs (for ghc at least). Cabal doesn't support -split-objs at the moment. To do this you'll need to write your own Makefile and hook it up to Cabal (possible, but a bit fiddly I believe). Cheers, Simon

3 3

Workaround for building profiling libs and apps with Cabal
by Satnam Singh 16 Jun '05

16 Jun '05

I recently tried to build a version of an application with Cabal to use with profiling by simply adding: ghc-options: -prof -auto-all to my Cabal file but this did not work because the generated .hi interface files ended in .hi and not .p_hi as expected and the .o and .a files also did not have the expected names. As a work-around I wrote a small script "fixhi" to create symbolic links for the expected filenames. The script can be adjusted to perform a rename by substituting the "ln -s" with "mv". The script is at the end of the message. It is designed to be run in the install directory of the package for a specific version e.g. lagavulin> pwd /c/Program Files/lava/lava-0.1 lagavulin> fixhi Symbolically linking ./Lava/Below.hi to ./Lava/Below.p_hi Symbolically linking ./Lava/Beside.hi to ./Lava/Beside.p_hi Symbolically linking ./Lava/Bit.hi to ./Lava/Bit.p_hi Symbolically linking ./Lava/Classes.hi to ./Lava/Classes.p_hi Symbolically linking ./Lava/Col.hi to ./Lava/Col.p_hi <...lots of lines deleted...> Symbolically linking ./Xilinx/Adder.hi to ./Xilinx/Adder.p_hi Symbolically linking ./Xilinx/Comparator.hi to ./Xilinx/Comparator.p_hi Symbolically linking ./Xilinx/Components.hi to ./Xilinx/Components.p_hi Symbolically linking ./Xilinx/OneBitAdder.hi to ./Xilinx/OneBitAdder.p_hi Symbolically linking ./Xilinx/OneBitSubtractor.hi to ./Xilinx/OneBitSubtractor.p_hi Symbolically linking ./Xilinx/Subtractor.hi to ./Xilinx/Subtractor.p_hi Symbolically linking ./Xilinx.hi to ./Xilinx.p_hi Symbolically linking ./HSlava-0.1.o to ./HSlava-0.1_p.o Symbolically linking ./libHSlava-0.1.a to ./libHSlava-0.1_p.a lagavulin> Application of the script should be idempotent. A simple change could allow the script to take a path to the installation so it can be run from elsewhere (e.g. a Makefile). I also expected when I used ghc --make to compile my programs that use this library to also be automatically compiled with "-prof -auto-all" but I guess that must be another option to Cabal and I had to add this to the ghc compilation command for the clients of this library. Hopefully the next version of Cabal will make it easier to build profiled and non-profiled versions of libraries and applications. Until then maybe the script below might provide some utility to others. I've only tested it under Microsoft Windows with msys (other OS-es are kind of hard to come by where I work). Cheers, Satnam Singh Microsoft One Microsoft Way Redmond Washington 98052-6399 USA #!/bin/sh # Workaround script for producing profiling interface files and libs # with the expected extension for use with Cabal. # Find and symbolically link to the interface files. for intfFile in `find . -name "*.hi" -print` do echo Symbolically linking $intfFile to ${intfFile%*.*}.p_hi ln -f -s $intfFile ${intfFile%*.*}.p_hi done # Find all the libraries and objects and link to them too. # First delete old profiling library files. rm -rf *_p.a *_p.o for objFile in `find . -name "*.o" -print` do echo Symbolically linking $objFile to ${objFile%*.*}_p.o ln -f -s $objFile ${objFile%*.*}_p.o done for libFile in `find . -name "*.a" -print` do echo Symbolically linking $libFile to ${libFile%*.*}_p.a ln -f -s $libFile ${libFile%*.*}_p.a done

3 2

RE: Default prefix for Cabal on Windows
by Simon Marlow 16 Jun '05

16 Jun '05

On 16 June 2005 09:08, Axel Simon wrote: > On Wed, 2005-06-15 at 20:56 -0700, Daan Leijen wrote: >> I think that "c:\Program Files" is already too cluttered, maybe we >> should use: >> >> 1) C:\Program Files\Haskell\<package-name>-<version> >> >> or >> >> 2) C:\Haskell\<package-name>-<version> >> >> where "Haskell" could also be "Packages" I guess. > > I strongly reject Daan's point :-). The prefix should come from the > registry, since that is the Windows way. "C:\Program Files" doesn't > even exists on foreign-language Windows machines. And programs which > assume they know that C: is the right (i.e. only) hard disk are a > pain, since you can do a network install where only Registry entries > are local. Ok, so $(ProgramFiles) is determined by the registry. Taking into account comments so far, I think we have: prefix = $(ProgramFiles)\Haskell\$(PackageName)-$(Version) libdir = $(prefix)\$(Compiler)-$(Version) bindir = $(prefix)\bin these are only defaults - users & packagers are free to change them. Sound reasonable? Cheers, Simon

2 1

Cabal help please
by Adrian Hey 16 Jun '05

16 Jun '05

Hello, I'm just getting around to tidying up the AVL library and releasing a new version and, of course thinking about Cabalising it too. But I'm finding difficult to figure out how to do this from the Cabal docs and Distribution library haddock. Anyway, what I want to do is.. Run cpphs on all the sources Compile the results using -split-objs (for ghc at least). Put the all the resulting objs in libHSDataTreeAVL.a Run haddock on some of the sources (but not all). .. and I'd like to do this without depending on gnu make. So could someone tell me if this is possible with Cabal as it is at the moment? (and if so, how I should do this). Thanks -- Adrian Hey

2 1

RE: Default prefix for Cabal on Windows
by Simon Marlow 16 Jun '05

16 Jun '05

On 15 June 2005 05:49, Brian Smith wrote: > The documentation states in Section 3.1 that the default value of > "prefix" is "/usr/local" on Unix. However, it doesn't specify what the > prefix is on Windows. I found that the default value for prefix is: > C:\Program > Files\<package-name>\<compiler-name>-<compiler-version>. For example, > version 1.0 of a package named "Foo" compiled with GHC > 6.5 would have a default prefix of: > C:\Program Files\Foo\ghc-6.5 > > I think that a better default value of prefix on Windows would be: > C:\Program Files\<package-name>-<package-version> > e.g.: > C:\Program Files\Foo-1.0 > > In particular, I think it is undesirable to have the name and version > of the compiler embedded in the default prefixes. Ok by me to add the package version. The compiler version is there to avoid conflicts in the case when you have multiple versions of GHC installed and the package is installed for each one. However, I don't think we currently include the compiler & version in the default $(libdir) on Unix, so whatever we do we should do it consistently. Cheers, Simon

5 4