Tried searching on Google but can't seem to find any information.
I need to execute a pkg file which exists within a dmg file via code. Reason is software update. I download an update via my application (which is a dmg) and need to run it. On Windows this is pretty straightforward: run the exe. Having trouble figuring out how to achieve this on a Mac.
As far as frameworks go, I'm using wxWidgets with cocoa (if that helps).
I don't know of a way to do this directly with cocoa APIs, but you can use external commands to do it: use /usr/bin/hdiutil attach /path/to/image.dmg to mount the disk image, then something like /usr/sbin/installer -package /Volumes/mountedvolume/installer.pkg -target / to install the package (see man installer for more information and options). Note that if the package requires admin rights to install, you'll need to run the installer command as root.
EDIT: to get the full path of the mounted volume, you'll probably have to parse the output of hdiutil. It'll look something like this, although it'll depend significantly on the format of the disk image:
/dev/disk2 Apple_partition_scheme
/dev/disk2s1 Apple_partition_map
/dev/disk2s2 Apple_HFS /Volumes/mountedvolume
Related
I'm creating a Qt gui application using a library which searches the PATH environment variable for certain executables, namely compilers, make and cmake.
The problem is that std::getenv("PATH") returns something different in the gui and certain executables are missed. I've tried to use the QProcessEnvironment class to the set the PATH, however, the same problem arises. I can set it to specific paths in my machine but it would be great if it could get the PATH of any machine the application is deployed to.
Strangely if I start the gui using the command-line, everything works out fine! Although I find it unreasonable to ask users to open the gui using the command line.
Any help would be greatly appreciated.
This problem has nothing to do with Qt. You've set the PATH using shell initialization scripts and such, in your own user folder. It'd be a terribly bad idea for the graphical shell to use that path, as a mistake in your shell profile would potentially make the entire desktop non-functional. Of course it works from the command line, since your shell profiles take effect then.
You could, as a user configuration option, extract the shell PATH by running the equivalent of user's $SHELL -c 'echo $PATH', and processing the result.
Otherwise, you'll have to defer to what's customary on the platform, and consult package managers if needed. Different package systems tend to install these tools in different directories, but there is just a few common ones. I presume it'd be enough to cover Ubuntu, RedHat, macports and homebrew, and make sure that you check in "pure" FHS (Filesystem Hierarchy Standard) locations as well.
I'd like to download Qt. I tried to download it from Qt's website but this gives me an exe file and since I've got a limited account when I try to run it it asks for an admin password. I've searched the web for a way for a limited account to install Qt but I haven't found anything. Could someone please help me find a solution?
In case it matters, I'm using Code::Blocks and Windows 7.
You could download the free software source code and compile and build it on your machine (that takes about a whole night, or maybe more). Don't forget to configure the build appropriately (I don't know Windows, but on Linux I'll suggest explicitly setting the -prefix to some writable directory ...). Before starting, ask explicitly your boss for permission (if you violate your company policies, you can be fired at once), and ask for guidance from someone knowing your operating system better than you do. You might need to change your PATH too.
Alternatively, ask permission to install and use a Linux distribution.
PS. Be sure to get permission to do something (even if technically you can do it alone).
You can download this ZIP file with Qt. All you have to do is unzip the ZIP file (which will take time) and place the files it contains in the right folder, nothing that requires administrator privileges. I recommend you put the contents of the ZIP file in C:\Qt, otherwise it might not work correctly (if this folder doesn't already exist, you can create it without administrator privileges and if it does exist, Qt is probably already installed on your computer in which case you don't need to do anything). I've also posted Qt's license agreement as it is in the installer program here since Qt wants you to read it before you use Qt.
Furthermore, I recommend using Qt Creator to make your Qt projects instead of Code::Blocks, because it's difficult to get Qt5 to work with Code::Blocks and Qt5 is the version of Qt used on both this website and Qt's installer (see this question) (if you find a way to get Qt5 to work with Code::Blocks, all the better, maybe you could even answer the question for which I posted a link). Qt Creator is included in the ZIP files on my website and to use Qt with Qt creator, all you have to do is include the right header files, no linking is needed. The path of Qt Creator is in the table on the bottom of the website.
You can download an archived distribution of MSYS2. After you extract and run it, you can use its packet manager to download numerous packages, including Qt. The only downside is you will have to settle for the version it provides, which is a little old, currently 5.5.1. You can install by typing:
pacman -S mingw-w64-i686-qt5 // for 32bit build or
pacman -S mingw-w64-x86_64-qt5 // for 64bit
This will install Qt and all dependencies automatically. Make sure your antivirus is not running in the final stage, because it can mess with the binary patcher that patches Qt to run from its current installation folder (because advanced software like Qt apparently cannot work without hard-coded paths).
You can even get a static build of Qt, which is quite useful, just add a -static to the package name.
Just in case you were wondering - MSYS2 is a build environment, it can come quite in handy, for getting ready to use libraries, or for building libraries which require a build environment. You can build Qt without it, however, it is a very slow process that may fail, and even though it is not complex to do, I would not recommend it as a first option.
If you still decide to build it from source, there is a detailed guide which will get you through the process.
If you have an application which relies on another app being installed, you ideally want your installer to find that dependency path automatically. On Windows you can use the registry but what about Mac/Linux? In this particular case it's a C++ application, if that makes a difference.
If you try to distribute your application through any of the common package managers on Linux (apt, yum) you can add the application as a dependency.
If you down the route of custom install scripts you need to resort to some kind of hackery. Either find out which package manager is in use on the system and try to query with it (which can fail, if the other application was installed without the package manager) or try something like which required_app.
Go for the first, if you want to do it right.
In Mac OS X, if you're looking for an application that's bundled in a typical .app bundle, you can use Spotlight to find it from its bundle ID using the command line utility mdfind(1). For example, to find out if Firefox is installed (and where), run this command:
mdfind 'kMDItemCFBundleIdentifier == org.mozilla.firefox'
Generally, on UNIX systems you can expect all programs to reside in $PATH instead of being distributed in a hodge-podge collection of stupidly named and partially localized directories. So, essentially you don't need to find any dependency path - you just call the other "app" (program) via execvp, and the libc takes care of walking through the entries of $PATH and finding the executable.
In the classic UNIX model, you don't check anything in an installer, but just check at runtime whether an executable is available (with which, for example) or not.
The equivalent of a Windows Installer is the Linux Package Manager. The Package Manager handles dependencies and installs it (if it is not already present on the system). The dependency information for an application is stored within the package file. Each distribution has its own Package Manager, though the concept is the same.
There are plenty of resources online for specifics about a Package Manager. However, if you would like to get an overview in comparison with a Windows Installer, check out application management in GNU/Linux for Windows users.
I have a SDL app that compiles fine, and the images show up, but only if they are in the correct folder with the binary next to them, if the images are moved they wont show up next time the application is run. How can I make a complete binary that will allow me to compile the images as well as the code, so that I can distribute one single binary, and not a zip file with all of my assets. I have looked into writing a .deb file which is what I think I need, but the process looked complicated. I am running Ubuntu 10.10 I only need to distribute to Ubuntu
I suggest making a .deb file. If you really seriously want to distribute anything for Ubuntu, you will have to get comfortable with dpkg sooner or later.
Now there is a Right Way to create packages, described in the Debian New Maintainer's Guide.
And then there's the dirty hippie way. For that you just need (a) a directory with a particular structure, containing all the files you want to distribute; (b) a control file with a particular format; and (c) dpkg-deb -b mydir which produces mydir.deb. None of this is all that hard. You could be up and running in a few minutes.
You can use bin2c to create embeddable static arrays.
I've completed a simple numbers-version of the game "Towers of Hanoi" using xcode's command line tool in C++. Being accustomed to PC compilers like borland's and visual-c, I've attempted to "share" the game with others via e-mail by simply attaching the executable product built by xcode. However, the recipients can't run the program as it shows up in a different format - usually machine code, it sounds like.
After a bit of extensive searching, I'm realizing the complexity of building projects within xcode's IDE and the variations on the build settings/ targets, etc.
Anyone know how to build a self-contained c++ executable to be universally run? I don't go outside the STL library for this game. I'd greatly appreciate any help.
thanks
OS X is based on Unix, which uses plain binary files (i.e. no filename extension) as executables. If they have a certain "executable permission," they can be double-clicked to be run as executables, or run from the command line. However, this permission can't be sent over email - it's metadata within the file system itself, and this makes sense from a security standpoint (you wouldn't want spammers sending you executable viruses over email right?). So when the recipient receives the binary, they'll need to run the following command line command on it, assuming "hanoi" is the name of the binary file:
chmod +x /path/to/hanoi
If you really want to package it as an instantly double-clickable application, you'll need to give it a native UI and package it as a .app, then put that .app (which is actually a folder with the .app extension) in an archive to distribute. Sorry if that's more work than you were hoping for. Hope this helps!
Sharing applications across dot releases of the same OS can be notoriously difficult on the Mac (at least, as far as personal experience goes).
In order to be able to share your application with the least amount of effort, you will need to figure out:
What project type is this? Are you using any resources like images etc?
What version of the OS your friends are using? If they are not on the Mac, you're out of luck (or you'll have to recompile for their OS-es).
If they run Mac, check out that you have the same OS versions, if you have developed on Leopard and someone's running on SnowLeopard your application might simply fail. (I also ran into issues between Mac OS 10.5.4 and 10.5.3 so keep your fingers crossed.)
Check out what sort of hardware you are running. Are you building for your hardware (say, MacIntel) only or are you creating an Universal Binary?
Make sure that all resources are packaged into your application bundle. Make sure your application uses only relative paths.
Check if you are not writing to special folders (i.e. use only temp and/or word-writable locations, if you need to).
I wish I could give a more detailed/to the point reply but unfortunately you'll have to figure out some of the answers yourself (without any other specific information about the error you are getting).
If you're satisfied with a command line tool rather than a double-clickable app, it should suffice to zip it and attach that to the e-mail. Be sure to build universal if anyone you're sending to might be using a PowerPC-based Mac. Oh, and set the deployment target to the minimum OS that any recipient might be using.