Closed jpcofr closed 8 years ago
Thanks. Apparently, we are not allowed to write in /usr/bin anymore.
Can you try this package: https://ci.zjyto.net/job/BNFC/job/bnfc-bdist-mac/lastSuccessfulBuild/artifact/dist/BNFC-2.8-mac.pkg
Thank you so much, that helps a lot!
I would like to add that it did not work to install it though 'cabal install bnfc' either. It is System Integrity Protection(aka rootless) feature that was introduced in El Capitan that is the cause. Since it restricts access to the path where transformer package is installed. There is however a way around it:
@seanpavlov do you run cabal as root or does El Capitan prevents you from installing stuff even in your home directory??
After upgrading to El Capitan, I ended up removing everything Haskell related on my system as follows:
rm -rf ~/.cabal
rm -rf ~/Library/Haskell
sudo /Library/Haskell/bin/uninstall-hs all --remove
brew uninstall ghc cabal-install
And then installing again through homebrew with: brew install ghc cabal-install
.
Maybe a bit extreme, but this gives you GHC 7.10.2 which seems to work well with SIP enabled.
However now I get a compile error when trying to build BNFC 2.8:
src/LexBNF.x:166:38:
Not in scope: ‘ord’
Perhaps you meant one of these:
‘or’ (imported from Prelude), ‘odd’ (imported from Prelude),
‘ord#’ (imported from GHC.Exts)
Using:
Ok, I managed to build by making a few small changes, as shown in pull request #161
Thanks to @johnjcamilleri's fix, the latest version on hackage should fix this problem. Please re-open if id doesn't.
It's not a big thing, but the current bnfc version in the master branch of the github repository is 2.8 whereas the uploaded cabal file at hackage (an the version in branch 2.8.x) already has version 2.8.1.
I am actually not sure whether this is a mistake or it is just me not understanding the idea of both branches. Sorry to bother you with such small issues.
The idea is that the new features implemented in master should be released as 2.9.0 but I wanted to release a fix for the new GHC, so I created the 2.8.x branch as a maintenance branch for 2.8.0.
Apparently cabal won't let me use "master" as a version but I can remove the version field altogether. Maybe it would be clearer to have no version in master and add one when a release is created?
Thanks for the explanation. I think the current work flow is useful as it is. I just wanted to make sure that implementing new features in the master branch follows the projects' guidelines, since I often saw it the other way around (a development branch for new features and the master containing bug fixes for the current version).
The installer fails for some reason. I guess that the problem is the new OS X security system but the error is not meaningful and I could not test my guess.