I have a mac application that uses twain (Relies on 3 packages that I had to install: libusb, sane backends, and twain sane interface) and imagemagick which I also used a package to install and I'm not really sure how to go about redistributing them.
I'm thinking I would have to include the source for each package I rely on, libusb-1.0.9.tar.bz2 for example for the lib usb package, and then configure and make each of those in /use/local/bin (Basing that off seeing it done by the binary packages). I imagine I would have to add these locations to $PATH once done.
I was trying this myself but ran into this error: "configure: error: no acceptable C compiler found in $PATH" so am now downloading xcode developer tools. I imagine the end user for my installer will run into this issue as well though if they don't have it installed so I'm now not sure how to proceed.
Can anyone shed some light on how to properly distribute tools that your app relies on? I am using FileStorm Pro and was planning on using applescript shell commands to do the command line work.
Unless you were planning to distribute your application as source, you definitely don't want to distribute its dependencies as source. Most Mac users do not have the Xcode developer tools, and do not want them.
Build the binaries on your machine (ideally on a clean machine with the oldest version of OS X you want to support, the newest version of Xcode that works on that OS, and nothing else installed on it). Then copy the resulting binaries somewhere into your .app bundle. Then, instead of running the tools in a way that relies on $PATH, launch them by an explicit path relative to argv[0] or [NSBundle mainBundle].
(And make sure to check the licenses of every third-party tool you're using.)
Related
I would like to compile a binary that is portable like a "normal" macOS bundle app.
For example using https://formulae.brew.sh/formula/cherrytree to create a macOS app that I can then share on a computer that do not have brew.
I know I can compile it using gcc directly. But is their a way to automatize library download and statically link those to the target binary?
I thought someone may have extended homebrew to do that?
I am also trying to create an app bundle which uses Homebrew packages but does not require other users to have Homebrew. The best I have been able to do so far is to install Homebrew inside the app bundle, for example, into a folder
/Applications/myApp.app/Contents/Homebrew
This has a big downside - it takes up a huge amount of disk space, of which only a small fraction is needed at runtime. You can clean it out by hand some after building, but it's painful.
Homebrew says installing into non default location is not officially supported, but it has been working OK. OTOH, the other Mac package manager, MacPorts, does officially support arbitrary install locations, but it doesn't actually work. Go figure...
I have a C# application that works great in Linux and Windows. Now I want to make an installation package for the Mac OS but I don't have anything running it in order to develop it / test it. The software is open source, so I don't want to put money into buying yet another laptop just to test it.
Is there a way to create some kind of installer / package for this C# application without actually needing to have a Mac? I even made a .deb package for Linux. Isn't it possible to somehow convert it?
It depends on how fancy you want to get with the installer. I'd start with something simple like building a package for Homebrew.
That's all command-line, though. If you think your Mac users would be unhappy installing an running from the command-line, you'll have to look into more sophisticated solutions. Mac GUI applications are traditionally built into .app bundles. Unfortunately for you, C# does not have lots of support for cross-compiling to the Mac. It's possible, but it's going to take a lot of trial and error, which will be way more frustrating without a test machine to see if you're doing it right.
You might try CPack (part of CMake). CMake doesn't really do C# (otherwise it'd be perfect for you), but you may be able to point CPack at the completed binaries and get it to bundle them up for the Mac for you. You could also use CMake/CPack to build a dummy Mac application and then you'd be able to swap out all the pieces for your own binaries.
I'm building and OS X app that needs a set of dynamic libraries in order to run (Graphviz Libraries). On the machine I'm developing on it works fine but when I tried running the app on another machine the app crashes (which does not surprise me) probably because it doesn't find the libraries, they are installed but in a different location.
My question is what is the best way to make sure your program works?
Graphviz libraries should be installed into "/usr/local", but can be installed in other places.
There are ways to include dylibs in application packages you build (this related question's answer has more info), but it's a bit of a hassle to set up the build steps / phases in Xcode to do the extra steps at build time (such as calling "install_name_tool" to point to "#executable_path").
If your app is going to be installed on not too many machines, I'd recommend just making certain that Graphviz is properly installed into the expected place. If you're going to distribute this app far & wide, you might as well include the Graphviz dylibs within your app package. A third -- possible -- option might be to call the Graphviz installer as a sub-installer from an installer that you create.
Is it possible to develop cross-platform application on Windows and can also compile for Mac OS X from Windows? I have checked Qt but that requires one to compile from Mac using Xcode.
If this is your priority then one option would be Java as at least a jar file built on one platform can be run on another.
If however you're talking about C or C++...
If you are creating a small command line tool then you might be able to make this work with gcc and a cross compiler, but I think it would be a lot of work.
If however you are wanting to create a GUI application I would urge you to give up now. There are so many issues - you'd have to use Carbon or Cocoa APIs which you can't build for on any other platform, you'd have to link against frameworks which won't exist on your compilation host, you won't be able to easily generate .plist files. Qt won't help as you need to be able to build it, which relies on these same frameworks.
In short, there's no alternative to building on an actual mac.
Furthermore, when it comes to fixing bugs, you will absolutely have to do this on a mac (either physical or virtual).
From what I know , in general you do need a mac to make the executable , even for a simple ansi c program you need gcc for mac.
You can create MacPorts Portfile.(If your application is open source)
A MacPorts port is a set of specifications contained in a Portfile
that defines an application, its characteristics, and any files or
special instructions required to install it. This allows you to use a
single command to tell MacPorts to automatically download, compile,
and install applications and libraries.
Take a look at IMCROSS.
IMCROSS is a simple, scripted method of installing cross-compilers and
cross-compiled libraries on a Linux (or possibly other *nix) system,
so that you can develop programs targeted to run on Microsoft Windows
and Mac OS X at the same time and in the same environment as you
develop Linux versions of those programs.
You can certainly do this using Real Studio. It can create Mac OS X applications on Windows without any trouble.
It cross-compiles for Windows, OS X and Linux. And it does it from any platform. It also can create web apps.
Sounds like you should check it out.
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