I agree with this comment in regards to cabal building binaries for similar reasons that John Macheam is. Cabal is fine for libraries (in fact I can classify it as pretty damn good) but for binaries it is a different matter for programs that don't use a simple build system/structure. Cabal is just too inflexible, and then you have the issues with no uninstall (if the binary also happens to create libraries) which just makes things more painful<div>
<br></div><div>In all honesty, using a CMAKE like system for Haskell would have had a lot more advantages then cabal for binaries.</div><div><br></div><div>The minute you have to install binaries on Windows using cabal that bring in C (and other dependencies) and things are much more complicated then they should be and are likely to break far too often then is considered sane</div>
<div><br></div><div>In my opinion this is one of the few things that is holding Haskell back in regards to it being adopted by Windows users (among other things)<br><br><div class="gmail_quote">On Fri, Aug 27, 2010 at 9:13 AM, Andrew Coppin <span dir="ltr"><<a href="mailto:andrewcoppin@btinternet.com">andrewcoppin@btinternet.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">Simon Marlow wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If you look at the original Cabal design document[1], you'll see that one of the goals of Cabal was to be the glue that lets you convert an arbitrary Haskell library into a native package for a variety of systems - including MSIs on Windows. Indeed, I must admit when we were designing Cabal I thought that native packages would be the most common way that people would install Cabal packages, specifically because many systems already have a good package manager, and trying to bypass the system package manager would be a fundamental mistake. It turned out that cabal-install would be a lot more useful than I imagined, but the two systems are complementary: native packages are for installing globally, and cabal-install is for installing packages in your home directory.<br>
</blockquote>
<br></div>
Why would you ever want to install a package per-user? I mean, if you don't have permission to do a global install, then you also don't have permission to install GHC in the first place so...? Indeed, the *only* plausible reason I can think of is if you're trying to build something that has unusual package version constraints, and you want to build it without upsetting the entire system.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Even on systems without a package manager (i.e. Windows), it would make more sense when installing a package globally to build an MSI first, so that the system can track the installation and let you uninstall it later.<br>
</blockquote>
<br></div>
I did have a look at building a binary installer using Nullsoft NSIS. Unfortunately, I don't know of any tool in existence that can build MSI files that isn't absurdly expensive. (E.g., InstallShield is ~£4,000, which is extortionate for a program that just copies files around. Even BackupExec isn't *that* expensive, and that's mission-critical!)<br>
<br>
Of course, *I* was looking at NSIS specifically for installing Haskell-to-C bindings. These are virtually impossible to build on Windows, and I figured if I could build such a package once, I could then make a binary installer out of it and never again have to build it from source. (Until the next GHC version, anyway.) But I utterly failed to make the building part work, so I never got to the next bit.<br>
<br>
If you were to use binary installers for regular Haskell packages, the only real benefit would be that you can now UNinstall them again. It might be worth doing that, and it looks plausible that you could automate it...<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[1] <a href="http://www.haskell.org/cabal/proposal/" target="_blank">http://www.haskell.org/cabal/proposal/</a><br>
</blockquote>
<br></div>
Interesting. So Cabal was never intended to handle executables at all. (The entire proposal speaks only about *libraries*.) Suddenly several of Cabal's deficiencies make a lot more sense. It doesn't handle executables properly because it was never designed to. It doesn't uninstall because Cabal packages are supposed to be converted into real packages first, and real package managers provide uninstall capabilities. And so on.<br>
<br>
It's slightly disturbing how the proposal meantions "make" every three sentences. You realise that make only exists under Unix, right? There _are_ other operating systems out there...<br>
<br>
I also can't for the life of me work out why something *designed for* automatic processing is designed without machine-readable syntax. Even in this early proposal, Cabal is already using that horrid ad hoc undocumented file format that only Cabal itself can actually parse and understand. Why not XML or JSON or *something* with a formal spec and a wide range of available tools? It makes no sense at all. And in case somebody is sitting there thinking "It IS documented. It's simple, isn't it?", did you know that file paths have to be escaped like Haskell string literals? No, I bet you didn't. Where is this fact documented? It isn't. Why was this decided? I'm guessing it's an implementation accident rather than a deliberate decision. Now if this were XML or JSON, everybody would already *know* the escaping rules. And we'd have tools that know about these rules and can handle processing such files. People seem to think that Cabal's existing format makes it easier for humans to read and write, but personally I'm always left wondering exactly which constructions are or aren't permitted. Can I put several values on a line here, or do they have to be seperate lines? Do all the field values have to be indented by the same amount? How does Cabal figure out which fields are subfields anyway?<br>
<br>
In summary, I would be *so* much happier if we had a real file format rather than this ugly home-grown thing. Unfortunately, this would break everything on Hackage, so it will never be fixed.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[2] <a href="http://www.haskell.org/pipermail/cabal-devel/2007-August/000740.html" target="_blank">http://www.haskell.org/pipermail/cabal-devel/2007-August/000740.html</a><br>
</blockquote>
<br></div>
Also interesting. I've never heard of WIX before...<div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br></div>