I'm trying to decide what haskell installation is more appropriate for a Mac running El Capitan.
It seems there are at least two alternatives:
Install the haskell platform as indicated in https://www.haskell.org/platform/
Install the haskell platform as indicated in https://ghcformacosx.github.io/
What is the difference between the two distributions?
Will I be able to use Xcode as an Haskell IDE?
The main differences I see are:
Haskell for Mac OSX:
is relocatable
comes with stack pre-built
Haskell Platform:
installs in /usr/local/bin (requires root access)
comes with more pre-compiled libraries
comes with the programs happy and alex pre-built
Neither comes with explicit support for using Xcode as an IDE. Usually one uses Emacs or Atom or Vi to develop Haskell programs.
Related
How do I install a current Frama-C release and its prerequisites on Macs?
I have a laptop running Mac OS X 10.6.8 and a desktop running Mac OS X 10.7.5
which I can install software on. I also have access to a lab of machines
running Mac OS X 10.8 which our technical support people will install stuff on
if I ask nicely.
I have a student who is interested in program analysis and needs something
that we have a fighting chance of understanding and adding to. I was already
aware of Frama-C, and a colleague at another university recommended it.
I had previously tried to install Frama-C and failed miserably. The colleague
commented that he'd had the same experience. Well, times change. So I visited
the Frama-C web site, was more impressed and keener to have it than ever, and
set about it.
The frama-c.com download page doesn't have links to any binaries for the
current (Flourine 3) release for any platform. The link to installation
instruction takes me to a page that says to download the auto-installer.
What auto-installer?
There are instructions for an old version of Mac OS X, but following them
didn't work; loading one set of prerequisites as instructed produced a
state where the next prerequisite (gtksourceview) would not install.
Of course I checked the older releases, and I see that there's a Nitrogen
version for Mac OS X Leopard, but "Please untar the archive as root in /"
asks me to perform the impossible. I don't have a root account and will
never be given one (the machines all belong to the university). It is
perfectly possible to install gcc and clang anywhere you like; why does
Frama-C want to be in /?
In addition to Pascal's answer, you can also have a look to opam, which is a source package manager for OCaml applications. It appears to run on MacOS X, and there are packages for Frama-C's Oxygen and Fluorine.
All Frama-C binary packages want to install in / (precisely, in /usr/local/Frama-C) because Frama-C uses GTK+ and various GTK+-related libraries that were never designed to run from anything other than a fixed location. They load configuration files and resources from paths that have been hard-coded at compile-time. GCC and Clang install anywhere because they don't rely on GTK+. Like them, the command-line version of Frama-C can be relocated through various environment variables listed here.
Note that to take advantage of a binary package, you would only need one symbolic link pointing from /usr/local/Frama-C to the place where you really extracted the files, if your administrator(s) can grant you that. Binary packages only work for one OS X version. For packages available from the official website, this version is usually 10.6 (Snow Leopard).
I have ceased making Frama-C binary packages for two reasons:
by removing features and support for hardware configurations in each of the last two OS X releases, Apple has fragmented the OS X landscape in a way I don't have the time to deal with. You mention 10.6, 10.7 and 10.8 in your question. I also have Macs running each of 10.6, 10.7 and 10.8. They are all incompatible (when trying to build a software package that includes a compiler).
I have much less time available now that I am participating in the creation of a start-up that offers Frama-C-based static analysis to interested industrial users.
This said, Frama-C the Open-Source advanced research prototype continues to be developed and maintained, and continues to be a great testbed to experiment in. You can install Frama-C without root access on a Mac in two ways apart from what you have already tried:
Install only the command-line version. Then the only dependency is a recent version of the OCaml compiler. Frama-C's configure will detect that you do not have the GTK libraries and will not try to use them. Installation should take 20 minutes at most for a recent OCaml + the latest Frama-C.
Install a recent Linux distribution in a virtual machine. Use that distribution's package manager to obtain all the GTK+ dependencies. If the distribution's OCaml package is recent enough, use that and then the lablgtk-2 package, otherwise, compile OCaml and then lablgtk-2 from source. Then compile Frama-C.
For Fluorine, the oldest supported OCaml version is 3.12.1.
with macports:
export PKG_CONFIG_PATH=/opt/local/lib/pkgconfig
sudo port install opam
opam init
Y
eval `opam config env`
sudo port install gtksourceview2 lablgtk2 ocaml-ocamlgraph
opam install frama-c
Hi stackoverflow community!
I am about to start developing patches for FreeBSD Ports Collection (pkgng utility) using C programming language.
The problem is that I am using Mac OS X and I am really do not want to switch to another operating system. I have installed Freebsd 9.0 on Parallels Desktop VM. Xcode 4.1 seems to be rather nice development tool for C.
Is it possible to implement development for FreeBSD via Xcode 4.1? How to set up project environment for such form of development and compile source for FreeBSD?
I am also opened for any other suggestions concerning cross-platform development using MacOS X to develop patches for FreeBSD. Which is the best way to organize all necessary stuff?
Since you want to develop patches for pkgng, I would strongly suggest that you compile and test the code on FreeBSD, because it is the only system that uses the ports and packages system that pkgng interfaces with. So unless it can cross-compile for FreeBSD, using any OS X IDE is probably not a good idea.
I'm not familiar with Parallels, but there is probably a file-sharing mechanism that you can set up between OS X and the FreeBSD running in the VM. That way you can edit your files on OS X and use them under FreeBSD.
X Code is really nice, and I would lean toward using it but then doing regular builds on a system actually running FreeBSD. If you have source for everything you're using (except standard libraries whose interfaces match), there is no reason not to work on OS X with Xcode. You can build your own libraries if need be. One thing writing cross platform does (provided you regularly build on the other platform) is make your code more portable. It's easier to avoid using platform specific "extensions".
I want to make a Ruby extension for a C (with C++ libraries) program that will run on a CentOS server, but it would be more convenient for me to work on a Mac (especially without having to reinstall all the 3rd party libraries).
Since they're both UNIX-based, would creating the library in OS X throw it off once I put it on CentOS, or should I just man up, install CentOS, and do it all there?
Thanks!
You don't even have 100% source compatibility between them, although you can easily stick to what will work on both.
There is no binary compatibility between Linux and OS X; even the basic object file formats differ (Linux uses ELF, OS X uses Mach-O).
I'm using Mac OS X 10.5.8. Another question indicated that Leksah is the IDE of choice for Haskell development.
However, Leksah (version 0.10.0.4) requires GHC 7.0.3 (problems with 6.12.2, problems with 6.12.3). Unfortunately, the newest Haskell platform available for OS X 10.5.8 is 6.12.3.
How do I get Leksah working on my Mac? An OS upgrade is not possible. Should I just use a different IDE/text editor?
According to the latest State of Haskell survey, the most popular IDE's are vi and Emacs, both of which have Haskell-mode features and are quite usable on OS X.
That said, it's probably worthwhile to get ghc-7 anyway. Is self-compiling an option? You can install a ghc-6.12 binary, then use that to bootstrap compiling ghc-7.0.3. Once you have a working ghc-7, download the Haskell Platform Source and build that. Compiling both ghc and the full platform will take a while, but I'd expect it all should work.
This is ghc 7.0.4 for Leopard PPC: https://downloads.haskell.org/~ghc/7.0.4/krabby/
I was also able to use it to build ghc 7.6.3.
I am sort of switching to a Mac based development environment as the Mac line of laptops and workstations contains some very nice systems, albeit pricey. As an occasional Emacs developer, I want to build Emacs from the git/bazaar sources. Much to my surprise, the first time I attempted to do this using Xcode4, I discovered that the version of autoconf supplied with Xcode is less than that required by Emacs. So this raises the question: what approaches do those who develop Emacs daily using Mac hardware take in order to have the required libraries and headers available to build and run the Emacs development code on OS X? Left to my own devices, I will fetch and build the versions of components required by Emacs that are not satisfied by Xcode and put those into /usr/local/... but it does occur to me that other approaches, using fink for one example, might be less work and/or more satisfying, hence the question. This also applies to the add-on packages for graphics support (pdf, dvi, png, etc.) that are not supplied by Xcode.
The directions in the file nextstep/INSTALL is to issue the following commands:
./configure --with-ns
make install
The resulting "app" can be found in nextstep/Emacs.app.
However, there is an XCode project provided with Emacs, but I haven't got it to work.
I use the macports package 'emacs-app', which is just emacs configured --with-ns. They're currently at version 23.2.1
Even if you want to build emacs direct from GNU repos, using macports to get autotools should save you some time and energy. The autoconf package is at 2.68, and emacs configure.ac requires 2.65