There is a bash script to build a Mac OS X .app bundle from an application written in Go that works by extracting the necessary libraries, resources, etc. from a Homebrew installation and tweaking the libraries. I'm happy adding MacPorts support, but..
Aren't there easier ways to do this, like using Xcode projects or whatever? Is there an analog of py2app for go? What should I know about using outside libraries in .app bundles?
If I understood you properly, you want to pack a Go binary as a OS X .app file. Well, yes, you can do it. Take a look on Makefile of my cocoa-go project. In fact, building .app if fairly easy. Also, I can recommend a Developer Library article about bundles — Bundle Programming Guide.
Related
Is there a more or less official way for Gtk+ applications to create regular OS X .app with all needed resources and libraries, placed in correct way?
Pretty much everyone does their own thing. Check out the outdated (read: not really maintained) bockbuild, as well as the build scripts that gedit uses for building .dmg.
https://github.com/mono/bockbuild
https://git.gnome.org/browse/gedit/tree/osx
This is something I'd love to see migrated to a configure/automake addition with dmg targets.
the easiest way to deploy a GTK based app on macOS:
How to deploy GTK based app on Mac OS X?
You should read it.
Ok so I am an engineer / applied-math guy and someone only mildly technical was impressed by a linux version of some software but wants it for Mac (Doctors...)
Can someone point me at how to redistribute an executable for Mac? Before I ditched Windows the atomic solution was to copy a bunch of DLL's into their System32 folder. Some sub-questions:
1) Ok I see "sudo macports install XYZ". Will this allow me to statically build QT apps? Or, suppose they have QT installed, how do I get my app to find it on their comp?
2) Maybe there's an example out there, using VTK + QT + Boost, for building application for Mac?
My apologies with the vague question, if I knew what to methodically search for I would have done so.
Is there any specific reason why you want to statically link Qt+VTK+Boost with the app? On the Mac, for libraries like these I can't think of any reason (except licensing) why static linking would be preferable to dynamic.
Take a look at the "Deploying an Application on Mac OS X" link that Bavarious posted. It explains how Mac apps are stored in bundles, allowing an app made up of many files to appear to the user as a single file. Libraries can also be stored in a bundle (along with their header files), in which case it's called a framework. Any needed frameworks can be stored inside the app bundle, making the app self-contained.
Qt comes with a utility called macdeployqt which automatically copies the Qt frameworks (plus plugins) into the bundle, then fixes up the app binary (using install_name_tool) so the dynamic linker knows to look in the app bundle. You'll probably need to do this manually for VTK and Boost, which could be more complicated if they aren't built automatically as frameworks. They are popular libraries though, there should be guides on the Internet about deploying Mac apps with VTK/Boost.
Also, I would not use MacPorts to install Qt for this purpose. The Qt binaries available from Nokia work just fine, and they are universal (built for both 32-bit and 64-bit, in case you need to target both).
By the way, I'm not particularly a Windows guy, but I don't think throwing DLLs into System32 is a good way to deploy libraries on Windows. For a Qt app I made, we put the Qt DLLs (and mingw/gcc DLLs) into the same folder as the .exe, and it worked fine.
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.
I know Python has py2app. I was wondering if Ruby has anything like that. I know there is OCRA (One-Click Ruby Application builder) for Windows, but what about for Mac OS X?
Take a look at Platypus; it may do what you want.
From its homepage:
Platypus is a developer tool for the
Mac OS X operating system. It can be
used to create native, flawlessly
integrated Mac OS X applications from
interpreted scripts such as shell
scripts or Perl and Python programs.
This is done by wrapping the script in
an application bundle directory
structure along with an executable
binary that runs the script.
Edit per #XtraSimplicity in a comment: Platypus can't handle any input or output from stdin or stdout. That will rule it out in some cases.
MacRuby seems like the most likely candidate without knowing more details about what you're doing. It can make standalone native binaries.
http://www.macruby.org/ for more info.
RubyCocoa includes a script (standaloneify.rb) to package all the Ruby files your project uses into the app wrapper, and MacRuby (recommended if you're targeting 10.5+) compiles to native code and thus it's no more work making a standalone app than with Objective-C.
Compared to Windows, Ruby and Python are prebuilt for Mac OS X, so the easiest way might be using Cocoa with Ruby. You can get good information out of the book Programming Cocoa with Ruby.
What installer software for macintosh would you recommend? It has to support leopard & snow leopard. Be easily scriptable and not expensive.
Thank you,
Nava
Best answer is: don't.
The "Mac Way" is to provide just a .app that the user can drag into /Applications or ~/Applications. The .app is really a directory that contains all the program's assets: code, properties, imagery, etc.
The only time you need to build an installer package is when you're modifying the system. In the Mac world, that's seldom the right answer.
OS X's built-in installer can be scripted, either via shell script (or any other executable) at particular stages of the install, or customized much more pervasively using JavaScript. Read the Software Delivery Guide for OS X.