Search Results

Search found 32 results on 2 pages for 'cabal'.

Page 1/2 | 1 2  | Next Page >

  • Haskell's cabal dependency problem with happy

    - by wirrbel
    I have problems installing ghc-mod on my linux machine. cabal worries about "happy" not being available in versione = 1.17: $ cabal install ghc-mod Resolving dependencies... [1 of 1] Compiling Main ( /tmp/haskell-src-exts-1.14.0-1357/haskell-src-exts-1.14.0/Setup.hs, /tmp/haskell-src-exts-1.14.0-1357/haskell-src-exts-1.14.0/dist/setup/Main.o ) Linking /tmp/haskell-src-exts-1.14.0-1357/haskell-src-exts-1.14.0/dist/setup/setup ... Configuring haskell-src-exts-1.14.0... setup: The program happy version =1.17 is required but it could not be found. Failed to install haskell-src-exts-1.14.0 cabal: Error: some packages failed to install: ghc-mod-3.1.3 depends on haskell-src-exts-1.14.0 which failed to install. haskell-src-exts-1.14.0 failed during the configure step. The exception was: ExitFailure 1 hlint-1.8.53 depends on haskell-src-exts-1.14.0 which failed to install. However, it even is installed in v. 1.19, as you can see here: $ cabal install happy Resolving dependencies... [1 of 1] Compiling Main ( /tmp/happy-1.19.0-1124/happy-1.19.0/Setup.lhs, /tmp/happy-1.19.0-1124/happy-1.19.0/dist/setup/Main.o ) Linking /tmp/happy-1.19.0-1124/happy-1.19.0/dist/setup/setup ... Configuring happy-1.19.0... Building happy-1.19.0... Preprocessing executable 'happy' for happy-1.19.0... [ 1 of 18] Compiling NameSet ( src/NameSet.hs, dist/build/happy/happy-tmp/NameSet.o ) [ 2 of 18] Compiling Target ( src/Target.lhs, dist/build/happy/happy-tmp/Target.o ) [ 3 of 18] Compiling AbsSyn ( src/AbsSyn.lhs, dist/build/happy/happy-tmp/AbsSyn.o ) [ 4 of 18] Compiling ParamRules ( src/ParamRules.hs, dist/build/happy/happy-tmp/ParamRules.o ) [ 5 of 18] Compiling GenUtils ( src/GenUtils.lhs, dist/build/happy/happy-tmp/GenUtils.o ) [ 6 of 18] Compiling ParseMonad ( src/ParseMonad.lhs, dist/build/happy/happy-tmp/ParseMonad.o ) [ 7 of 18] Compiling Lexer ( src/Lexer.lhs, dist/build/happy/happy-tmp/Lexer.o ) [ 8 of 18] Compiling Parser ( dist/build/happy/happy-tmp/Parser.hs, dist/build/happy/happy-tmp/Parser.o ) [ 9 of 18] Compiling AttrGrammar ( src/AttrGrammar.lhs, dist/build/happy/happy-tmp/AttrGrammar.o ) [10 of 18] Compiling AttrGrammarParser ( dist/build/happy/happy-tmp/AttrGrammarParser.hs, dist/build/happy/happy-tmp/AttrGrammarParser.o ) [11 of 18] Compiling Grammar ( src/Grammar.lhs, dist/build/happy/happy-tmp/Grammar.o ) [12 of 18] Compiling First ( src/First.lhs, dist/build/happy/happy-tmp/First.o ) [13 of 18] Compiling LALR ( src/LALR.lhs, dist/build/happy/happy-tmp/LALR.o ) [14 of 18] Compiling Paths_happy ( dist/build/autogen/Paths_happy.hs, dist/build/happy/happy-tmp/Paths_happy.o ) [15 of 18] Compiling ProduceCode ( src/ProduceCode.lhs, dist/build/happy/happy-tmp/ProduceCode.o ) [16 of 18] Compiling ProduceGLRCode ( src/ProduceGLRCode.lhs, dist/build/happy/happy-tmp/ProduceGLRCode.o ) [17 of 18] Compiling Info ( src/Info.lhs, dist/build/happy/happy-tmp/Info.o ) [18 of 18] Compiling Main ( src/Main.lhs, dist/build/happy/happy-tmp/Main.o ) Linking dist/build/happy/happy ... Installing executable(s) in /home/hope/.cabal/bin Installed happy-1.19.0 Any ideas? cabal-install version 1.16.0.2 using version 1.16.0 of the Cabal library

    Read the article

  • Cabal: Odd Error Message + Lack of Documentation

    - by voxcogitatio
    So I recently installed cabal (from the default binary of ArchLinux). I then tried to upgrade cabal as a user: cabal upgrade Cabal --user --prefix=$USER Resolving dependencies... cabal: fromFlag NoFlag. Use fromFlagOrDefault What I've already done: Googled the error message. Turned up the cabal source and little else. Looked at haskell-wiki on cabal-install. Looked through this guide. So basically I'm wondering: What's up with the error message? Could anyone point me in the direction of a cabal tutorial?

    Read the article

  • Enable --hyperlink-source for "cabal install"

    - by Tener
    The command cabal haddock has very useful --hyperlink-source option. I would like to have the source hyperlinked when building documentation with cabal install. The ticket #517 seems to be just about it: http://hackage.haskell.org/trac/hackage/ticket/517 However, perhaps it is possible to set this flag via ~/.cabal/config file? If not, how can I get working cabal-install build with the patch from #517 without installing Cabal-0.9, which is currently mandatory (due to one patch from December)?

    Read the article

  • Enable --hyperling-source for "cabal install"

    - by user263407
    The command cabal haddock has very useful --hyperlink-source option. I would like to have the source hyperlinked when building documentation with cabal install. The ticket #517 seems to be just about it: http://hackage.haskell.org/trac/hackage/ticket/517 However, perhaps it is possible to set this flag via ~/.cabal/config file? If not, how can I get working cabal-install build with the patch from #517 without installing Cabal-0.9, which is currently mandatory (due to one patch from December)?

    Read the article

  • Getting Cabal to work with GHC 6.12.1

    - by Dan Dyer
    I've installed the latest GHC package (6.12.1) on OS X, but I can't get Cabal to work. I've removed the version I had previously that worked with GHC 6.10 and tried to re-install from scratch. The latest Cabal version available for download is 1.6.0.2. However, when I try to build this I get the following error: Configuring Cabal-1.6.0.2... Setup: failed to parse output of 'ghc-pkg dump' From what I've found searching, this seems to suggest that the version of Cabal is too old for the version of GHC. Is there any way to get Cabal to work with GHC 6.12.1 yet? EDIT: To be clear, I'm trying to set-up cabal-install.

    Read the article

  • ghc can't find my cabal installed packages

    - by nont
    I've installed ghc 6.12.3, and then the Haskell Platform. I'm trying to compile a test program: $ ghc test.hs test.hs:3:0: Failed to load interface for `Bindings': Use -v to see a list of the files searched for. so, naturally, I do cabal install Bindings Which works fine, and places the package in ~/.cabal/lib/bindings-0.1.2 The problem is, that when I go to compile again with ghc, it still doesn't find the package I've installed with cabal. compiling in verbose mode gives: ghc -v test.hs Using binary package database: /home/ludflu/ghc/lib/ghc-6.12.3/package.conf.d/package.cache Using binary package database: /home/ludflu/.ghc/x86_64-linux 6.12.3/package.conf.d/package.cache As suggested by another stackoverflow user, I tried: ghc-pkg describe rts > rts.pkg vi rts.pkg # add the /home/ludflu/.cabal/lib to `library-dirs` field ghc-pkg update rts.pkg But to no avail. How to I add the .cabal to the list of package directories to search? Thank you!

    Read the article

  • What is a good method to solve cabal install problems?

    - by sp3ctum
    I've used the cabal package manager for Haskell programs to install libraries and new projects that I've cloned from some repositories. More often than not, I keep running into problems. Most projects make installing them seem super easy, but in my case that's not always true - sometimes they are very hard to get running. Some are so hard, in fact, that I've lost interest in the project solely because of not being able to install it. So instead of complaining, I'd like to ask what I should do to better this situation. I'd like to use my most recent problem as an example. I'm interested in trying out the Gitit project. It's a promising looking personal wiki that runs on various version control systems. So here's what I've done: Clone from Github run cabal install in the project directory like I'm told on the project install page: mika@eka:~/git/gitit$ ls BLUETRIP-LICENSE CHANGES HCAR-gitit.tex LICENSE Network README.markdown RELANN-0.6.1 Setup.lhs TANGOICONS YUI-LICENSE data expireGititCache.hs gitit.cabal gitit.hs plugins mika@eka:~/git/gitit$ cabal install Resolving dependencies... cabal: cannot configure happstack-server-7.0.7. It requires base64-bytestring ==1.0.* For the dependency on base64-bytestring ==1.0.* there are these packages: base64-bytestring-1.0.0.0. However none of them are available. base64-bytestring-1.0.0.0 was excluded because gitit-0.10 requires base64-bytestring ==0.1.* mika@eka:~/git/gitit$ So now I'm thinking: well, I'll install happstack-server on its own, maybe that will work: mika@eka:~/git/gitit$ cabal install happstack-server Resolving dependencies... Warning: happstack-server.cabal: Ignoring unknown section type: test-suite Configuring happstack-server-7.0.7... cabal: At least the following dependencies are missing: blaze-html ==0.5.*, hslogger >=1.0.2, monad-control ==0.3.*, network >=2.2.3, sendfile >=0.7.1 && <0.8, system-filepath >=0.3.1, text >=0.10 && <0.12, threads >=0.5, transformers-base ==0.4.* cabal: Error: some packages failed to install: happstack-server-7.0.7 failed during the configure step. The exception was: ExitFailure 1 So looks like there are some dependencies missing. But isn't installing these dependencies the whole point of using cabal in the first place? What should I do? File bug reports (to which project?), install the dependencies manually or something else? Bonus points for explaining what causes these kinds of problems.

    Read the article

  • Multiple Haskell cabal-packages in one directory

    - by aleator
    What is the recommended way of having several cabal packages in one directory? Why: I have an old project with many separable modules. Since originally they formed just one program it was, and still is, handy to have them in same directory for easy compiling. Options Just suffer and split everything, including VCS holding the stuff, into different directories? Hack cabal until it is happy with multiple .cabal files in same directory? Make another subdirectory for each module and put .cabal files there along with symlinks to original pieces of code? Something smarter? What?

    Read the article

  • Weirdness with cabal, HTF, and HUnit assertions

    - by rampion
    So I'm trying to use HTF to run some HUnit-style assertions % cat tests/TestDemo.hs {-# OPTIONS_GHC -Wall -F -pgmF htfpp #-} module Main where import Test.Framework import Test.HUnit.Base ((@?=)) import System.Environment (getArgs) -- just run some tests main :: IO () main = getArgs >>= flip runTestWithArgs Main.allHTFTests -- all these tests should fail test_fail_int1 :: Assertion test_fail_int1 = (0::Int) @?= (1::Int) test_fail_bool1 :: Assertion test_fail_bool1 = True @?= False test_fail_string1 :: Assertion test_fail_string1 = "0" @?= "1" test_fail_int2 :: Assertion test_fail_int2 = [0::Int] @?= [1::Int] test_fail_string2 :: Assertion test_fail_string2 = "true" @?= "false" test_fail_bool2 :: Assertion test_fail_bool2 = [True] @?= [False] And when I use ghc --make, it seems to work correctly. % ghc --make tests/TestDemo.hs [1 of 1] Compiling Main ( tests/TestDemo.hs, tests/TestDemo.o ) Linking tests/TestDemo ... % tests/TestDemoA ... * Tests: 6 * Passed: 0 * Failures: 6 * Errors: 0 Failures: * Main:fail_int1 (tests/TestDemo.hs:9) * Main:fail_bool1 (tests/TestDemo.hs:12) * Main:fail_string1 (tests/TestDemo.hs:15) * Main:fail_int2 (tests/TestDemo.hs:19) * Main:fail_string2 (tests/TestDemo.hs:22) * Main:fail_bool2 (tests/TestDemo.hs:25) But when I use cabal to build it, not all the tests that should fail, fail. % cat Demo.cabal ... executable test-demo build-depends: base >= 4, HUnit, HTF main-is: TestDemo.hs hs-source-dirs: tests % cabal configure Resolving dependencies... Configuring Demo-0.0.0... % cabal build Preprocessing executables for Demo-0.0.0... Building Demo-0.0.0... [1 of 1] Compiling Main ( tests/TestDemo.hs, dist/build/test-demo/test-demo-tmp/Main.o ) Linking dist/build/test-demo/test-demo ... % dist/build/test-demo/test-demo ... * Tests: 6 * Passed: 3 * Failures: 3 * Errors: 0 Failures: * Main:fail_int2 (tests/TestDemo.hs:23) * Main:fail_string2 (tests/TestDemo.hs:26) * Main:fail_bool2 (tests/TestDemo.hs:29) What's going wrong and how can I fix it?

    Read the article

  • ghc-pkg vs cabal

    - by Ben Lever
    In relation to how packages are created, installed and used in Haskell, what are the differences between ghc-pkg and cabal? When would you use one or the other or both? Are they complementary tools, competitive tools, or simply tools that do different jobs?

    Read the article

  • How can my-program.hs get its version number from my-program.cabal at build time?

    - by Dave Hinton
    I would like my cabalised program to have a --version switch. I would like it to report the same version as is present in the .cabal file. If I have to update the version number separately in my Haskell source code as well as in the .cabal file, I will eventually get them out of sync. So, how can my program, while being compiled under cabal, get its version number from the .cabal file?

    Read the article

  • C compiler selection in cabal package

    - by ony
    Today I've tried C compiler (Clang) for C code I use in my haskell library and found that I can gain speed increase in comparsing with my system compiler (GCC 4.4.3) from 426.404 Gbit/s to 0.823 Tbit/s So I decided to add some flags to control the way that C source file is compiled (i.e. something like use-clang, use-intel etc.). Snippet of cabal package description file: C-Sources: c_lib/tiger.c Include-Dirs: c_lib Install-Includes: tiger.h if flag(debug) GHC-Options: -debug -Wall -fno-warn-orphans CPP-Options: -DDEBUG CC-Options: -DDEBUG -g else GHC-Options: -Wall -fno-warn-orphans Question is: which options in descritpion file need to be modified to change C compiler used to compile "c_lib/tiger.c"? I did found only CC-Options.

    Read the article

  • How do I get Cabal to bypass my Windows proxy settings?

    - by Brent.Longborough
    When retrieving packages with Cabal, I frequently get errors with this message: user error (Codec.Compression.Zlib: premature end of compressed stream) It looks like Cabal is using my Windows Networking proxy settings (for Privoxy). From digging around Google, Cabal or its libraries appear to have (had) a problem in this area. Possible solutions I can see are: Turn off proxying while using Cabal (not very keen on this one); or Get a patch and start hacking. I'm hesitant to go down this path, as I'm a complete Haskell noob and I'm not yet comfortable with Darcs; or Give it the magic "can I haz no proxy" parameter. Hence the question.

    Read the article

  • Cabal and zlib on OS X

    - by Bill
    When I run "cabal update" on my Mac (Snow Leopard, Intel), I get: % cabal update Downloading the latest package list from hackage.haskell.org cabal: Codec.Compression.Zlib: incompatible zlib version Anyone else seeing this? Reinstalling the Haskell Platform hasn't helped. I'm unable to install or update Cabal packages at the moment, so I'd appreciate any help. Thanks!

    Read the article

  • What are best practices for managing related Cabal packages?

    - by Norman Ramsey
    I'm working on a dataflow-based optimization library written in Haskell. It now seems likely that the library is going to have to be split into two pieces: A core piece with minimal build dependencies; call it hoopl-core. A full piece, call it hoopl, which may have extra dependencies on packages like a prettyprinter, QuickCheck, and so on. The idea is that the Glasgow Haskell Compiler will depend only on hoopl-core, so that it won't be too difficult to bootstrap the compiler. Other compilers will get the extra goodies in hoopl. Package hoopl will depend on hoopl-core. The Debian package tools can build multiple packages from a single source tree. Unfortunately Cabal has not yet reached that level of sophistication. But there must be other library or application designers out there who have similar issues (e.g., one package for a core library, another for a command-line interface, another for a GUI interface). What are current best practices for building and managing multiple related Haskell packages using Cabal?

    Read the article

  • Are there tools that would be suitable for maintaining a changelog for a Cabal Haskell package?

    - by Norman Ramsey
    I'm working fast and furiously on a new Haskell package for compiler writers. I'm going through many minor version numbers daily, and the Haskell packaging system, Cabal, doesn't seem to offer any tools for updating version numbers or for maintaining a change log. (Logs are going into git but that's not visible to anyone using the package.) I would kill for something equivalent to Debian's uupdate or dch/debchange tools. Does anyone know of general-purpose tools that could be used to increment version numbers automatically and add an entry to a change log?

    Read the article

  • Weird cabal error: "inappropriate type"

    - by Bill
    ~ % cabal install --reinstall time Resolving dependencies... [1 of 1] Compiling Main ( /var/folders/0D/0D3du+YyGzuRETgUJZ5m8U+++TI/-Tmp-/time-1.2.0.251774/time-1.2.0.2/Setup.hs, /var/folders/0D/0D3du+YyGzuRETgUJZ5m8U+++TI/-Tmp-/time-1.2.0.251774/time-1.2.0.2/dist/setup/Main.o ) Linking /var/folders/0D/0D3du+YyGzuRETgUJZ5m8U+++TI/-Tmp-/time-1.2.0.251774/time-1.2.0.2/dist/setup/setup ... Configuring time-1.2.0.2... setup: dist/setup-config51799.tmp: inappropriate type cabal: Error: some packages failed to install: time-1.2.0.2 failed during the configure step. The exception was: ExitFailure 1 ~ % Has anyone seen this before?

    Read the article

  • Does any method exist quickly to detect valid range versions of used library

    - by daneel-yaitskov
    I'm a beginner Haskell programmer. I have written some useful code for the last six month. And I want to release a library from it. The code will use system installation cabal as any Haskell library. A library is released with cabal has a meta data file where there is a logical predicate from the libraries and their versions. A developer usually uses one set libraries. It tediously care a set of the sets libraries. How to know either my library is compiled successfully or not for some subset libraries?

    Read the article

  • Manipulating source packages from Hackage how to easy deploy to several windowsboxes?

    - by Jonke
    Recently when I have found good sources packages for ghc 6.12/6.10 on Hackage I've been forced to do some minor or major changes to the cabal files to make those packages to work under windows. Besides to fork and merge my fixes with github, what seems to be the best way/ good enough practice to take these modified builds to a couple of other windows boxes that only has a basic haskell platform installed? I should prefer if I somehow could work with the cabal-install because that is what one normally use. Should one put the modfied build dirs on a shared/networked dir and mount from the targeted windows box? Say something like this: on machine prepare cabal fetch foo cabal unpack foo cd foo edit .cabal and .hs cabal configure cabal build On machine useanddevelopnormal cd machinepreparemount cd foo cabal install

    Read the article

  • hackage package dependencies and future-proof libraries

    - by yairchu
    In the dependencies section of a cabal file: Build-Depends: base >= 3 && < 5, transformers >= 0.2.0 Should I be doing something like Build-Depends: base >= 3 && < 5, transformers >= 0.2.0 && < 0.3.0 (putting upper limits on versions of packages I depend on) or not? I'll use a real example: my "List" package on Hackage (List monad transformer and class) If I don't put the limit - my package could break by a change in "transformers" If I do put the limit - a user that uses "transformers" but is using a newer version of it will not be able to use lift and liftIO with ListT because it's only an instance of these classes of transformers-0.2.x I guess that applications should always put upper limits so that they never break, so this question is only about libraries: Shall I use the upper version limit on dependencies or not?

    Read the article

  • Installing EclipseFP on Mac OS X

    - by Dom Kennedy
    I am trying to install EclipseFP. I'm running OS X Mavericks. I've tried following both the official installation instructions and the advice in this answer on SU, but I'm still having the same problem. I can get the plugin itself installed painlessly using Help -> Install New Software..., Bbut when I restart and switch to the Haskell perspective, things start to go wrong. The installation instructions tells me that I should receive a prompt to install BuildWrapper and Scion Browser. I do not receive this prompt. Furthermore, if I create a new Haskell project, my code has no syntax highlighting, and the Hoogle search feature does not appear to do anything. It's clear that the plugin is not set up correctly yet. I've tried running cabal update in Terminal, but this does not change anything. After several attempts going round in circles with this on Eclipse Juno, I uninstalled Eclispe and the Haskell Platform and performed a clean install of Eclipse Luna and the latest Haskell Platform. However, the problems are persisting. I've tried going into Preferences to see if I could sort any of this out manually. I should initially point out that my GHC installation seems to be correctly references under Preferences -> Haskell Implementations Under Haskell -> Helper executables, there are areas for configuring the options of both BuildWrapper and Scion Browser. At present, both are blank. I tried clicking the Install from Hackage... button beside each of them with no success; I receive an error message saying Expected executable <workspace>/.metadata/.plugins/net.sf.eclipsefp.haskell.ui/sandbox/.cabal-sandbox/bin/buildwrapper not found!` (replace buildwrapper for scion-browser and the message is the same) The Eclipse console displays the following exception after doing the above with BuildWrapper: src/Language/Haskell/BuildWrapper/GHCStorage.hs:313:32: Not in scope: data constructor ‘MatchGroup’ cabal.real: Error: some packages failed to install: buildwrapper-0.7.4 failed during the building phase. The exception was: ExitFailure 1 and after doing it for Scion-Browser: zip-archive-0.2.3.4 (reinstall) changes: text-1.1.0.0 -> 0.11.3.1 pandoc-1.12.3.3 (latest: 1.13) -http-conduit (new version) Graphalyze-0.14.1.0 (reinstall) changes: pandoc-1.12.4.2 -> 1.12.3.3, text-1.1.0.0 -> 0.11.3.1 cabal.real: The following packages are likely to be broken by the reinstalls: pandoc-1.12.4.2 unordered-containers-0.2.4.0 aeson-0.7.0.4 scientific-0.2.0.2 case-insensitive-1.1.0.3 HTTP-4000.2.10 Use --force-reinstalls if you want to install anyway. After receiving similar results as the above on previous attempts, I've tried using force-reinstalls and ended up at more dead ends. I am at a loss as to what is wrong and how to solve this. I should point out that my GHC installation appears to be correctly configured under Preferences -> Haskell -> Haskell Implementations. Apologies if any of this information is irrelevant, I'm just not really sure what is important and what isn't at this point. Any help anyone could provide me with would be greatly appreciated.

    Read the article

  • GHC 6.12 and MacPorts

    - by absz
    I recently installed GHC 6.12 and the Haskell Platform 2010.1.0.1 on my Intel MacBook running OS X 10.5.8, and initially, everything worked fine. However, I discovered that if I use cabal install to install a package which depends on a MacPorts library (e.g., cabal install --extra-lib-dirs=/opt/local/lib --extra-include-dirs=/opt/local/include gd), things work fine in GHCi, but if I try to compile, I get the error Linking test ... Undefined symbols: "_iconv_close", referenced from: _hs_iconv_close in libHSbase-4.2.0.0.a(iconv.o) "_iconv", referenced from: _hs_iconv in libHSbase-4.2.0.0.a(iconv.o) "_iconv_open", referenced from: _hs_iconv_open in libHSbase-4.2.0.0.a(iconv.o) ld: symbol(s) not found collect2: ld returned 1 exit status After some Googling, I found a long Haskell-cafe thread discussing this problem. The upshot seems to be that MacPorts installs an updated version of libiconv, and the binary interface is slightly different from the version included with the system. Consequently, if you try to link with any MacPorts library, the MacPorts libiconv gets linked in too; and since the base library was built to link against a different version of libiconv, things break. I've tried setting LD_LIBRARY_PATH and DYLD_LIBRARY_PATH and adding more flags to try to get it to look at /usr/lib again (e.g. cabal install --extra-lib-dirs=/opt/local/lib --extra-include-dirs=/opt/local/include --extra-lib-dirs=/usr/lib --extra-include-dirs=/usr/include gd), but neither worked. Uninstalling the MacPorts libiconv isn't really an option, since I have a bunch of ports installed which depend on it---including some ports I want Haskell to link to, like gd2. From what I've seen online, the upshot really seems to be "you're boned": you cannot link against any MacPorts library while compiling with GHC, and there doesn't seem to be a solution. However, that thread was from the end of 2009, so I figure there's a chance that someone has a solution, workaround, ridiculous hack… anything, really. So: does anybody know how to get GHC 6.12 to link against the system libiconv at the same time as it links to libraries from MacPorts? Or, failing that, a way to make linking not break in some other clever way?

    Read the article

  • Why are there no package management systems for C and C++?

    - by m0nhawk
    There are some programming languages for which exist their own package management systems: CTAN for TeX CPAN for Perl Pip & Eggs for Python Maven for Java cabal for Haskell Gems for Ruby Is there any other languages with such systems? What about C and C++? (that's the main question!) Why there are no such systems for them? And isn't creating packages for yum, apt-get or other general package management systems better?

    Read the article

1 2  | Next Page >