Using spawn_posix to launch pkg (Writing Autoupdater for audio plugin) - c++

I'm writing an auto-updater for my audio plugin which is working fine on Windows, and I feel I'm close on MAC but need some help understanding how to programmatically launch the installer on mac. The algorithm is pretty simple:
Plugin checks in S3 to see if there's a newer version
If YES then plugin downloads the installer for the new version
Once downloaded the plugin should launch the installer and prompt the user to close the DAW (audio workstation)
This is working fine, I can download the installer on both platforms, and on windows launch it by using CreateProcess, but I can't find the right way to do it on mac. The closest equivalent I can find is "posix_spawn" in order to launch a process and then run "/user/sbin/installer -pkg /path/to/pkg /target", and although this is returning 0 indicating success I don't see any installer popping up on the screen. Ideally the user would see the UI of the installer as there are some options included.
How can I accomplish the goal of opening a PKG file visually for the user on mac using C++? OR, is there an alternative solution to accomplish the algorithm described above? Many thanks!

Related

Qmake on Windows

I have a project written in Qt that I have no problems compiling and running on Linux. The command line is:
qmake ../trunk/GSDTesting.pro
The process on Linux was really simple: install a few dependencies using apt and you are off.
My task is to recompile the same program on Windows using Visual Studio C++ compiler, but the problem is I don't know how to start. There is no such thing as qmake for Windows.
Can someone give me a few hints where to start. Please note that I don't know QT almost at all, my task is just to debug some issue unrelated to QT.
Are you using terminal exclusively on Windows? If so, maybe this image of example build steps straight from Qt Creater 4.14.2 may help you:
As you can see the image of the default Qt creator build steps list the file path where 'qmake.exe' can be located on a local installation of the toolchain.
If you can use a machine with a display I find using the Qt creator GUI is not all that bad.
Here is a link to the base get started page:
https://doc.qt.io/qt-5/gettingstarted.html
Here is a link to the installer download page:
https://www.qt.io/download
IMPORTANT:
You will need to make a Qt account, login to your account, and then download the open-source version of the API. The commercial version of the same source is acquired differently/seperately.
Otherwise, if you cannot use the GUI, can I request some clarification on why you cannot use Qt creator on your Windows installation?

Installing iCloud on XP PC

I'm trying to install iCloud on my Windows XP Pro (SP3) PC. Officially it's supported only for Vista and later, but this hack is widely claimed to work:
Open iCloudSetup.exe file and unzip its files including
Navigate to and open the iCloud.msi with Orca.
In the left table select LaunchCondition. Then change in the right table “VersionNT> = 600” to “VersionNT> = 200” and Save.
Run modified iCloud.msi and install.
Run iCloud Control Panel, located in the Windows Control Panel, and set up as you want.
I tried that promising solution in vain. It seemed to successfully install iCloud, but whenever I try to run it I get
this obscure error
After much fruitless searching I've not found out how to proceed from there and would appreciate advice please.
That trick worked with only the firs versions of iCloud Panel, the v1.0.
For the v2.1 doing the trick the installer ran ok, but when trying to run the iCloud Panel it showed the error you're refering to.
I had some computers running with that older version without any problem.
Try downloading the v1.0 version here:
http://icloud-control-panel-for-windows.uptodown.com/descargar/22412
If you want to try the trick with the v2.1 you have the installer here:
http://icloud-control-panel-for-windows.uptodown.com/
Remember you need to extract the MSI from the exe to do the trick. After running the exe check the %TEMP% folder to get the MSI file.

Qt C++ application: self autostart installation in Linux

I'm porting some Qt Windows/VC++ code to Linux/GCC. The application can add it's own shortcut to the Windows Autostart folder so the application starts after login.
I want to do the same in Linux. I'm using Kubuntu 15.10 but the solution should work for virtually all (or at least most) Linux variants out there. And it should work without super user rights (or it should request the rights automatically).
I searched the web and found two solutions:
Add a desktop entry file to $HOME/.config/autostart
Add a symbolic link to /etc/init.d/
Will they both work in all Linux distributions? What are the differences? Which is to be preferred?
Also I would like to know if I should do that by programmatically running a shell command or if there is some native API I could use in C/C++ (including easy error detection).
I have put project in GitHub for managing auto-start feature in different OS. It's written in Qt.
Please check it and let me know if you have any problem using it:
https://github.com/b00f/qautostart
You can add application in various ways.
Via linux init system. For newest linux OS systemd is a standard. In this case your need to create systemd unit for your application
Via desktop manager, such as gnome, kde and possible others. In this case you need also create specification for autostarting your app.
Via bash files
I think, prefered way via systemd unit, because now this is standard way for starting process at boot time and for special user, if need.

Creating set up for Qt Project

I have Qt application on Lnux. I want to create a executable/set up for this so as to distribute it on Windows and there is no need to install Qt. I have created the executable for this by including all the dlls
but to run it user needs to go inside the folder.
I want such user do not need to go inside any folder,he can directly click the icon can run it. Or such tha user downloads the set up, and install it.
What can be done for this?
You can use the Qt Installer Framework which could be downloaded here. The Qt Installer Framework provides a set of tools to create installers for Linux, Microsoft Windows, and Mac OS X.
You can compile the Installer Framework on your own, but i think using a prebuilt one is more convenient. You can see the Qt Installer Framework Manual for a complete guide on how to make off-line and on-line installers. Creating installers is described here.
A tutorial for creating simple installers for small projects is available here.

What is the recommended way for packaging a C++ daemon on Mac OSX?

I'm working on a multi-platform project that is composed of a service/daemon which runs on Windows, Linux, and Mac OSX.
The code I have is portable, and the application runs fine (from the command line) on all the systems. As this application is designed to run in the background, I made it a Windows service on Windows and a Linux daemon (with the appropriate scripts in init.d) for Linux.
Now my problem is Mac OSX: I have little experience with this operating system, and I am having hard times figuring out the best practices for it regarding my situation:
I'd like to have an installer for my project (I believe a .dmg file, that would likely install an .app; please correct me if there is a better alternative).
Here some information about this project of mine:
It is build entirely in C++ (it uses boost, curl, iconv)
The current build system is not XCode (however If there is a way of keeping my current code layout while integrating and building everything into XCode, I don't mind. I've done something similar for Windows anyway).
There is no graphical user interface
The daemon should start on startup automatically (or even better: make that a user's choice).
The daemon requires root access during its execution.
That's probably a lot of context to consider for a single question, so I will try to make it easier to read:
How would you package/create an installer for a pure-C++ daemon on Mac OSX ?
Since this doesn't have a UI, I wouldn't package it as a .app -- that's the preferred format for double-clickable GUI apps, not for daemons. If it's just a single binary (no support files except maybe things like config files, etc), I'd follow unix conventions and put the binary someplace like /usr/local/libexec (or wherever you put it on Linux). Note that /usr/local doesn't exist by default on OS X, so your installer will need to create it if it doesn't exist.
For getting it to execute: I'll agree with James Bedford's suggestion of using launchd. The launchd .plist file should be installed in /Library/LaunchDaemons (LaunchDaemons run as root at startup, while LaunchAgents run as normal users when that user logs in). Make sure the daemon does not drop itself into the background -- launchd keeps watch over the programs it launches, and if they background themselves it thinks they've crashed, and generally tries to relaunch them, which doesn't work very well. You can adjust the settings to work with background programs, but it's best to have it run in the foreground.
For packaging: Here, I agree with mah -- use an installer package. I actually still like the old GUI PackageMaker tool (deprecated, but it still works), but the new CLI tools are probably better to learn at this point. If you follow my recommendation about /usr/local/libexec, your package should actually contain the "local" directory (with libexec subdir and your binary in that), and install that into /usr -- if /usr/local already exists, it'll just merge with what's already there, but if not it'll create the entire thing. On the other hand, /Library/LaunchDaemons is guaranteed to exist, so your package only needs to contain the actual .plist file to put in it.
Packaging as a .app makes some sense if what you're distributing is more than just a command line (for example, if it has resources such as static configuration data, images, frameworks/dylibs) that need to come along with it).
Regardless of what exactly is getting distributed, you can create an installer using tools that you already have -- pkgbuild and productbuild, both in /usr/bin. Making OS X Installer Packages like a Pro - Xcode Developer ID ready pkg can get you started using these tools.
Have you checked out the Daemons and Services Programming Guide provided by Apple? I think that would be very helpful as an introduction to the platform and should point you in the right direction (if not show you how to do exactly what you want).
You should also check out launchd (which is discussed in that programming guide). launchd is the official deamon launcher/manager for OSX, and is heavily integrated with the operating system. It should be easy enough to wrap your existing cross-platform deamon into a launched deamon, and you can integrate with OS X so that the deamon will start up automatically.