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.
Related
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.
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 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.)
I have done a little work on lazarus' free pascal. So when a client asked me to write an application for a mac, after the initial, "it can't be done" stage. (followed by an asp.net maybe stage) i thought about writing it using lazarus.
Question is. I have only a virtual machine running mac OSX, this means that i do not really want to develop on the mac. However, i just cannot seem to get the applications that i have written in lazarus on windows to work on the mac. I have tried the deployment using the Lazarus Wiki and the MACOS folder is empty and so when i put it on the mac it doesn't run the application.
What is the best way of doing this or am i barking up the wrong tree?
It seems you want to do cross-compiling, which is theoretically possible, but may not be practical, for the reasons mentioned by Marco above.
As an alternative, you could install XCode, FreePascal, and Lazarus on a MacOX machine. You could still do your development and some testing on Windows/Linux. When you hit a certain milestone, you can copy your source code to the Mac and compile your application to test and give to the user.
Even if it were possible to easily cross-compile, there some minor differences between platforms, so (especially if it's a GUI app), you would want to test it on an actual MacOS box before giving it to the client.
I've taken the route described by Noah - and I was incredibly surprised that after about three weeks development on Windows, it took about 10 minutes to get the application running on the Mac.
My route was to install Xcode 4.3 on an old Mac Mini running snow leopard, then install Lazarus using the fink version as described here. This took a while but was done in an evening.
Then I just copied my folder across to the Mac, opened the lpi on the Mac, compiled it. It failed so I removed a windows references, recompiled, and it was working. I was truly amazed.
What linker and assembler do you use to generate binaries? To my best knowledge the linker for recent OS X versions is not available in source.
Afaik what you want (crosscompiling to Mac) is not possible for recent versions (and I've done it for PowerPC myself in the past).
The easiest is to use the Unix "file" command on the binary to see what is generated, and make sure it reads something with "MachO" in it. Easiest is if you have a Linux install (where this command is pretty standard), but versions can be found for windows too (cygwin, mingw and 3rd party)
All of the documentation I have seen regarding distribution of Adobe AIR apps suggests that an installer is required to be run in order to get the runtime and the app onto a system.
The environment I am working in requires the AIR runtime, the AIR app and associated DLL's (it will be calling Windows native processes) to be transferred to a clean system and this needs to happen without running an install package. Ideally in the form of just copying the necessary files (DLL's, resources etc..) to where they need to be. Scripts can be used for tasks like adding registry keys and similar requirements. The build needs to be automated in the form of a copy, hence why no installer packages are suitable.
Does anyone know whether this is at all possible with Adobe AIR? Note, the app is Windows-only so cross platform is not a requirement.
Thank you in advance for your help
I'm adding more details in this answer.
In order to use NativeProcess your app must be an EXE compiled by ADT using "extended-desktop." I didn't find much documentation ont his, but a normal air app installs silently like this
C:\AdobeAIRInstaller.exe -silent -eulaAccepted "C:\yourApp.air"
Since the ADT compiled EXE already contains air, you can acutally just do this
C:\yourApp.EXE -silent -eulaAccepted -location "\"C:\WhereToInstall\""
I don't believe you need a redistributable license to do this... but I could be wrong. It's easy to get and free so you might as well.
Where yourAPP.EXE is the extended desktop AIR app compiled by ADT. For compiling an EXE by ADT see: http://help.adobe.com/en_US/air/build/WS789ea67d3e73a8b22388411123785d839c-8000.html
No; this won't be possible. You'll have to install the AIR Runtime on the Windows machine to run an AIR app. And I expect the AIR app won't actually run w/o running the AIR App installer.
You may be able to look into alternate non-AIR options to turn SWFs into EXE. Zinc is one such software to do that.
Or it is possible you can create an invisible installer. I believe if you sign up for redistribution of the AIR Runtime there is a way to make the runtime installer "invisible". I'm not sure about the app, though.