I'm building my open-source game for MacOS in AppVeyor CI (which uses Catalina). I'm installing compiler and dependencies with brew and package it in .app format, and everything seems to work fine, except that when trying to launch resulting application in older MacOS versions (I only have High Sierra available for experimentation) I'm getting errors about newer MacOS version. I suppose if I can force Homebrew to install binaries for older MacOS versions, this would fix the problem, but how exactly can I do that?
I'm aware there's ability to build software from sources in brew, but I don't want to go that route considering I want my CI to be fast.
EDIT: To clarify, I'm trying to fix the following error: "You can't use this version of the application MyCoolGame with this version of macOS. You have macOS 10.13.6. The application requires macOS 10.15 or later."
Since time immemorial†, there have been two package managers for Macintosh computers: Homebrew and MacPorts. These projects are different in a variety of ways that some folks care about very deeply, and lots of people have opinions about which package manager is better. Once they all get tired of arguing, however, they usually acknowledge that Homebrew and MacPorts do basically the same thing, and return to more important topics like why tabs are better than spaces.
There is one particular difference between Homebrew and MacPorts which may interest you:
Homebrew supports the three most recent versions of macOS, which as of this writing is Monterrey, Ventura, and Big Sur. Homebrew can sometimes be installed on older operating systems too, but Homebrew's developers make zero effort to support these systems. The result is lots of breakage.
MacPorts also supports the three most recent versions of macOS. However, it also supports older versions of macOS on a "best-effort" basis. Notably, "best-effort" in this context is a term used to mean "a lot of f*cking effort." MacPorts actively maintains bespoke patches, hardware buildbots, and compatibility libraries for every version of macOS going back to OS X Tiger. (OS X Tiger, for those who don't know, is an operating system released in 2005. And 2005, for those who don't know, is a long forgotten age when phones were actually used to make phone calls, Zoom was just a TV series on PBS Kids, and Mug Cake hadn't been invented yet).
You stand at a crossroads. You have two choices. Do you:
Continue using Homebrew, with full knowledge that most packages will be broken and anything that is not broken will likely become broken in due course and at the least opportune time.
Use MacPorts, which actively supports your operating system and will continue to do so for the foreseeable future.
Choose wisely.
† aka the year of our lord 2009. That's basically the same thing, right?
Related
I am trying to install Haskell on Mac, and doing it as instructed on Haskell site Haskell site.
When I run the script from above website on terminal, it says to install "ghcup", "ghc" and "cabal". However, it seems that it installs "ghcup" successfully, but an error occurs when it comes to install "ghc".
Error: ghc: unknown version :lion
how can I fix this? or, is there another way to install Haskell on Mac?
(I saw similar posts but they are too old)
You seem to be running macOS Lion, which is ancient, insecure, and no longer supported by Apple. As such, most modern software isn't tested for compatibility with it anymore, and a lot of it won't work. Upgrading to a modern version of macOS such as Catalina will make it work.
There are different options to get a working Haskell development environment on your Mac. The most popular seem to be
Haskell Platform
Install via homebrew
The Haskell Tool Stack
Of course, you can also install most tools individually by hand or compile everything from source.
Together with the type of installation, you need to choose how to build your projects: Using Cabal or Stack.
My personal preferences as a beginner is Stack, because (a) the entire Haskell tool stack is installed locally for each project, so you don't get into problems with conflicting versions of certain tools; (b) dependencies are curated, such that you do not need to deal with incompatible versions of libraries. From a beginner's perspective, it is very helpful that I can focus on actual development work and less on infrastructure and tooling.
Ruby comes automatically installed on OS X. I assume when you get a new Mac it comes with the latest stable release of Ruby. Do you have to update it yourself manually over time, or does it get upgraded automatically when you upgrade your OS?
I assume when you get a new Mac it comes with the latest stable release of Ruby.
No, it comes with whatever release Apple felt confident to support for the lifetime of the OS release.
Do you have to update it yourself manually over time, or does it get upgraded automatically when you upgrade your OS?
Those two are not mutually exclusive.
Yes, it does get upgraded automatically, in order to, e.g., patch security vulnerabilities. However, an OS vendor will generally avoid updating anything they ship as part of the OS as much as possible, since they generally guarantee backwards-compatibility, and the easiest way to guarantee backwards-compatibility for third-party code that you have no control over, is to just not change it.
For example, macOS 10.14.6, which is the current release of macOS and was released 4 weeks ago, ships with Ruby 2.3.7, which was released 18 months ago.
The last release of Ruby 2.3 was Ruby 2.3.8, and the Ruby developers stopped providing security patches to Ruby 2.3 6 months ago. (Note that Apple does still provide security patches for Ruby 2.3 as part of macOS, though.)
So, yes, it does get upgraded automatically, with e.g. security fixes, but if you want a different version than the one shipped with the OS, you have to install it yourself.
Short answer: No.
Long answer:
If you just want a taste of Ruby, then no, you really don't need to do anything.
If you want to use Ruby to do something non-trivial, like beyond a "Hello, world!" application, then yes you should update.
The best approach is to use a Ruby version manager like RVM or rbenv where you can get the latest version of Ruby, specific historical versions if necessary for testing, as well as alternate implementations like JRuby and Rubinius.
These version managers make it possible to have multiple versions of Ruby installed simultaneously and you can switch between at any time. You can even pin different projects at specific versions if they haven't been updated to work with the latest Ruby, a common problem with older code-bases.
This pattern plays out with any language, be it Ruby, Python, Perl, Node.js, C# or what have you. If you're doing serious development in those languages the first thing you do is install a version manager and the best version for your situation.
I need some smalltalk with GUI for my homework, and I'm running Mac OS X Lion (10.7).
I've seen that unix users usually use GNU Smalltalk and GTK+.
I've tried to install them from different versions of sources and all of them give some errors.
Then I've used MacPorts, but that installation breaks GTK+ bindings for gst.
Finally I've tried to install it using fing package manager (because GNU states that I should install everything nice) but there is no smalltalk package for 10.7 OS (though there is for previous ones).
Is there some way to use smalltalk under Mac OS Lion, or should I for example run Ubuntu on virtual machine?
You could also try Pharo, which is a fork of Squeak.
http://www.pharo-project.org/home
Uko,
Have you looked at Squeak? Its an open source version of Smalltalk which is really fun to use and is supported on most platforms.
See:
http://squeak.org/
You will need a specific SqueakVM for the Mac:
http://www.squeakvm.org/mac/
Let me know if you have any further questions...
Squeak or Pharo are real Smalltalks (unlike GNU). This means they have a Smalltalk specific IDE. IDEs were invented by the creators of Smalltalk, so whatever you think you know about IDEs, you probably don't.
My video series, Squeak from the very start, shows how to download the latest Squeak Smalltalk and get started with it. Pharo isn't any harder to install either.
http://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all
You can also give the Personal Use version of VisualWorks a spin:
http://www.cincomsmalltalk.com/main/developer-community/trying-cincom-smalltalk/try-cincom-smalltalk/
I'm assuming you'll get a 7.8(.1?) version there. The OSX skin is pretty dated. I promise it's getting better. Look for 7.9 soon now.
I'm new at programming on the Mac. I've got me a brand new copy of XCode 4.0. I've got people asking me what versions of MacOSX we'll be able to support but I'm not sure what to tell them.
I see options for selecting an "SDK" and other options for selecting a target version. It seems the lowest I can go is 10.4 though -- even though we'd like to support 10.3, if possible without a lot of pain.
My question is, could anyone give me a quick rundown of how sdk versions and target versions fit into this? As I'm coding, what kind of things do I need to watch out for to make sure I can still support the smallest version of MacOSX? Likewise, how do I figure the G4/G5 (PowerPC) versions of MacOSX into all this? For example, on Windows, if I write an app in c#, I know that all I need to do is make sure an appropriate version of .net framework is installed, regardless of the OS. Does something similar hold true for the MacOSX?
Thanks in advance.
I believe Apple has dropped PowerPC support completely, including Rosetta, in Mac OS X so 10.3 is out of the question.
If you want to support PowerPC, see this related question. It looks like a lot of work.
How can we restore ppc/ppc64 as well as full 10.4/10.5 SDK support to Xcode 4?
With the analogy to the .NET Framework, there isn't anything like that for Mac OS X built-in.
It is true for Mac OS X. If your program targets 10.3 SDK, it will be able to run on 10.3 or greater. I.e. the Base SDK project setting specifies minimum target OS version.
However, supporting 10.3 IS a lot of pain. Even 10.4 is not that easy, for example Objective-C 2.0 (most important, #property, garbage collection) is only available with 10.5 SDK or above.
The common solution in existing projects is to keep an old version of software available for 10.1-10.4 users, while the new versions will require 10.5 or greater (and also usually are Intel-only).
If you're starting a new project, you will probably want to distribute it via Mac AppStore, which only works on 10.6+, which means you can safely pick 10.6 SDK as the lowest target version.
Apple is way more harsh about upgrades than Microsoft. Mac users don't walk around with 10-years old systems on their laptops. The only reasons I can think of to still use 10.3 are using 10-year old mac, not having Internet connection and not knowing what “to update a software” means. So, I wouldn't care even about 10.4, not to say 10.3.
What are the pros and cons of installing things like Python and Git from source instead of simply using the community provided Disk Image on OS X?
Dan Benjamin has an article about "Using /usr/local". However, given that the Git DMG installs into /usr/local/git and the Python DMG installs as a Framework, I'm not sure that the advantages Dan lists for building from source aren't still gained via a DMG install in these cases.
Obviously, one pro of using a Disk Image is that it's much simpler. However, are they tradeoffs that make it worth building from source?
There are two separate questions here: should add-on software you install go in /usr or /usr/local (short answer: it should go in /usr/local for the reasons Dan Benjamin gives), and should you install add-on software from a provided installer (disk image) or by building it yourself (short answer: whatever works best for you, but either way it should go in /usr/local).
I'll take Python as an example. OS X v10.6.6 includes python v2.6.1 in /usr/bin, with its frameworks in /System/Library/Frameworks. If you download an installer for a newer version (currently installers for v2.7.1 and v3.1.3 are available), it'll put the new version in /usr/local/bin, and its frameworks in /Library/Frameworks (/Library has roughly the same relation to /System/Library that /usr/local has to /usr), which is exactly what you want. If your paths are set properly, you'll use the newer version automatically. OTOH system scripts that may not be compatible with, say, Python v3 should start with #!/usr/bin/python, and keep using the old (standard) version. Furthermore, when OS X v10.6.7 ships and includes a relinked version of Python v2.6.1, it won't step on the update you installed.
If you were to build a newer version of Python yourself, you should do it just like the installer does: put the binary in /usr/local/bin and the frameworks in /Library/Frameworks, for exactly the same reasons. If you aren't sure how to do this, you should probably stick to the installer -- at least for major projects like Python and Git, there are likely to be smart people involved who know how to get this sort of thing right.