On 10/25/06, <b class="gmail_sendername">Duncan Coutts</b> <<a href="mailto:duncan.coutts@worc.ox.ac.uk">duncan.coutts@worc.ox.ac.uk</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Wed, 2006-10-25 at 09:39 -0500, Brian Smith wrote:<br><br>> Name: foo<br>> Version: 1.0<br>><br>> configuration: flag(debug)<br>> Name: foo-debug<br>><br>> Otherwise, how can I have a debug and an optimized configuration of a
<br>> given library installed at the same time?<br><br>You can't. No current Haskell implementation supports this (without<br>doing things manually like using separate package databases / search<br>paths).<br><br>What you want is what the ghc build system refers to as a 'way'. It's a
<br>whole other discussion I think.</blockquote><div><br>Yes, I am interested in building with different "ways" as you say. But, I think one of your examples used -DDEBUG. I think it is reasonable to want to install regular and debug versions of a package together.
<br></div><br>You said that no current Haskell implementation supports what I proposed. But, isn't this purely a Cabal issue. If I give a -debug flag to Cabal, and Cabal allows me to rename the package to foo-debug (by allowing me to put a name entry in the configuration stanza, like in my example), then foo and foo-debug can sit right next to each other in GHC or Hugs (at least). The user would do:
<br><br> runhaskell Setup.lhs configure -debug<br> runhaskell Setup.lhs build <br> runhaskell Setup.lhs install<br><br>Now, foo-debug is installed. Then:<br><br> runhaskell Setup.lhs configure<br> runhaskell
Setup.lhs build<br> runhaskell Setup.lhs install<br><br>Now, foo is installed too. Then, we can make packages that depend on either foo or foo-debug using the mechanism you proposed.<br> <br> Configuration: flag(debug)
<br> Name: bar-debug<br>
Build-depends: foo-debug || foo<br><br> Configuration: !flag(debug)<br> Name: bar<br>
Build-depends: foo<br><br>The only extension to your idea is being able to change the name of the installed package in the configuration. I think that this is a very desirable feature because it allows people to build packages with names that uniquely identify the configuration, if the choose to do so.
<br><br>Regards,<br>Brian<br><br></div>