I'm trying to have my app deploy to a user's applications directory on install, but am having trouble determining the correct configuration settings.
Right now I have:
Deployment Postprocessing - YES
Installation Build Products Location - ""
Installation Directory - "/Applications"
This seems to work when doing xcodebuild install, but is this the best way to do this? I had to change Installation Build Products Location from /tmp/Project.dst to an empty string which doesn't seem right. Also should these settings be set on the target, the project, or both?
These settings seem to work fine. They should be set at the project level, not the target.
Documentation of DSTROOT (Installation Build Products Location) says:
The path at which all products will be rooted when performing an
install build. For instance, to install your products on the system
proper, set this path to /. Defaults to /tmp/$(PROJECT_NAME).dst
to prevent a test install build from accidentally overwriting valid
and needed data in the ultimate install path. Typically this path is
not set per target, but is provided as an option on the command line
when performing an xcodebuild install. It may also be set in a build
configuration in special circumstances.
So the "official" way of doing it would be setting it to "/".
Related
I am getting the following error on Windows:
Cargo, the Rust package manager, is not installed or is not on PATH.
remote: This package requires Rust and Cargo to compile extensions.
I've installed Rust and cargo is in the path, but the problem persists. Does anybody know why this is happening?
Error message is the same as in this post.
Heroku's stack runs on Ubuntu. Cargo is required by pywinpty but that's a library required for communicating with Windows processes. You may need it for your local environment but you don't need it for Heroku. You should try removing pywinpty from your requirements.txt when you deploy to Heroku.
If you want a temporary solution
Open a command line prompt (cmd) and execute
path
that will show you the actual, current path. Inspect it to see whether the necessary directories are really absent. If they are, execute
path=%path%;directory you want to add;other directory you want to add
The path will be available in the command prompt for as long as it's open. If they are present, reboot the computer, the addition to the path may have been delayed after installation.
The permanent solution
For Win10 but I guess instructions are not very different for other flavors.
Open System properties, find Environment Variables. In the dialog that pops up you will see System Variables, among which you will see Path. Select it, click edit and add the directories you need via the New button. Close all popup boxes and reboot (always a good idea when Windows is stubborn ;-) )
I'm trying to create a CPack-based MacOS installer for an audio plugin project. The default location of MacOS audio plugin is in the /Library/Audio/PlugIns/ folder which needs root rights to be written to.
AFAIK CPack takes the destination path for the installed artifacts from the path specified in the CMake INSTALL command, so my CMakeLists.txt looks like that:
# CPack takes these paths as the locations where the plugins should be installed in the end
install (TARGETS MYPLUGIN_VST3 LIBRARY DESTINATION /Library/Audio/Plug-Ins/VST3 COMPONENT VST3)
install (TARGETS MYPLUGIN_AU LIBRARY DESTINATION /Library/Audio/Plug-Ins/Components COMPONENT AU)
# This makes sure that only the two components and nothing else is part of our installer
SET (CPACK_COMPONENTS_ALL VST3 AU)
# We want to use the native Apple GUI installer
SET (CPACK_GENERATOR productbuild)
Now, when I call cpack to build the installer it fails because of a permission issue as it installs the plugins as a first step before building the installer. The only solution I found was running cpack with root rights to let it write to these locations during the install step which seems like bad practice to me and might be even worse when trying to run this on a build server in future. As I don't need the install step but only want the resulting installer, I wonder if there is any way to avoid the install step and let CPack grab the files to wrap into the installer directly from the binary directory where they were placed after build. Didn't find anything regarding that in the documentations, but I'm just starting with CMake and CPack, so I might overlook something obvious here
I've seen this question asked but never specifically for Mac. My company is using TeamCity on a Mac Mini to do our iOS and android builds. We would use windows but, iOS builds require a Mac with Xcode. I have not been able to satisfy this condition. I can see that there are multiple versions of MSBuild (and Xbuild) already on my machine. Here is what I tried:
set an environment variable for MSBuildTools12.0_x86_Path using launchctl setenv (tried the bin directory of every instance of MSBuild existing on my machine), rebooted before checking TC
setting env.MSBuildTools12.0_x86_Path entry in buildAgent.properties
setting system.MSBuildTools12.0_x86_Path entry in buildAgent.properties
logging into TeamCity, going to my build configuration, going to the "parameters" tab and adding a new parameter for env.MSBuildTools12.0_x86_Path
After all of the above failed to satisfy the condition, I tried grabbing version 12 of MSBuild from a Windows machine, copying it to my Mac and pointing to its "Bin" directory instead, and repeating all bullets above.
The path was /Users/myusername/MSBuild/12.0/Bin. This bin directory contains MSBuild.exe, an MSBuild folder, a bunch of DLLs and more.
Again, this failed to change the outcome of the unmet condition in TeamCity. The frustrating thing is that TeamCity isn't giving me details. I don't know if it's still complaining that the path isn't even set (and where it is even looking for that path definition), or if it SEES that the path is set but it's not pointing to a folder it recognizes as MSBuild. I'm completely in the dark.
Does anyone have any guidance for me on this? I feel I've exhausted all paths to a solution. Thank you so much, in advance.
I figured it out on my own. On the Mac, you have to do an "MSBuild" runner type and pick "Mono xbuild 4.5" for the version. I used "x86" for the run platform and set a parameter for Mono4.5_x86 to point to xbuild. But it was trying to run the 64 bit version of mono and I found no way to set a command line argument for mono to tell it I want --arch=32 so I ended up having to link the mono executable to mono-sgen32 to get the build to finally work.
I have an XCode project with two executable targets, which I use for my own work (that is, I don't sell or publish the applications, but they are still important to me), which depends on one external project. Until now, it has been unproblematic to build the Application(s) and install into the /Applications folder. What I did, was go into the command line and type:
sudo xcodebuild -scheme Trainer install
This would install the target Trainer into the Applications folder, and the application could be run from there. If I tried to specify the target using -target Trainer instead, it would not work, as it would not find dependencies in the external project. Anyway, since last time it worked, two things have happened:
I have upgraded to OS X 10.11
I have upgraded XCode to Version 7.1.1 (7B1005)
Whatever the reason, xcodebuild does no longer install the built product into the /Applications folder. The last lines from the build log, when building with xcodebuild now are:
Touch /var/root/Library/Developer/Xcode/DerivedData/SoundSample-bvsqlgnuhfmtjkgkhevztdzbjbie/Build/Intermediates/ArchiveIntermediates/Trainer/BuildProductsPath/Release/Trainer.app.dSYM
cd /Users/pbholmen/Projects/SoundSample
/usr/bin/touch -c /var/root/Library/Developer/Xcode/DerivedData/SoundSample-bvsqlgnuhfmtjkgkhevztdzbjbie/Build/Intermediates/ArchiveIntermediates/Trainer/BuildProductsPath/Release/Trainer.app.dSYM
RegisterWithLaunchServices /var/root/Library/Developer/Xcode/DerivedData/SoundSample-bvsqlgnuhfmtjkgkhevztdzbjbie/Build/Intermediates/ArchiveIntermediates/Trainer/InstallationBuildProductsLocation/Applications/Trainer.app
cd /Users/pbholmen/Projects/SoundSample
builtin-lsRegisterURL /var/root/Library/Developer/Xcode/DerivedData/SoundSample-bvsqlgnuhfmtjkgkhevztdzbjbie/Build/Intermediates/ArchiveIntermediates/Trainer/InstallationBuildProductsLocation/Applications/Trainer.app
** INSTALL SUCCEEDED **
I have tried to simply copy the Trainer.app that it builds into the /Applications folder, but if I double-click on it, it just won't run. Of course, the Application works when built and run from within XCode, both with the "Debug" and "Release" configuration.
Back when it did work, this would be the last lines of the build log (in Terminal):
Touch build/Release/Trainer.app.dSYM
cd /Users/pbholmen/Projects/SoundSample
/usr/bin/touch -c /Users/pbholmen/Projects/SoundSample/build/Release/SoundSample.app.dSYM
RegisterWithLaunchServices /Applications/Trainer.app
cd /Users/pbholmen/Projects/SoundSample
builtin-lsRegisterURL /Applications/Trainer.app
** INSTALL SUCCEEDED **
If I try to go into the build log from within XCode, find where it puts the builds, and maneuver into that location in Finder and start the application from outside of XCode, that doesn't work either.
Here you can see my Deployment build settings for the target:
Build settings
Under "Deployment location" I have tried both "YES" and "NO", and under "OS X Deployment target" I have tried both "OS X 10.10" and "OS X 10.11". And all four combinations of the two.
After hours of twiddling, I finally figured out the answer. First off, the command
sudo xcodebuild -scheme Trainer install
is wrong. It was a workaround, because I couldn't get XCode to manage my external dependencies from the command line, even though they were managed correctly within XCode. The correct invocation, for a target other than the project's main target is
sudo xcodebuild -target Trainer install
Previously, the first invocation would work, the product would be installed even though the scheme doesn't really include an "Install" action. This is clearly no longer so with XCode 7.1. The reason I couldn't use -target instead of -scheme previously, was because my target was dependent on a framework in another project, which was added to my main project (the external project was added, not just the framework). All dependencies were set up correctly in my main project, and from the command line it worked only when specifying the scheme, not when specifying the target. When running xcodebuild with -target specified, xcodebuild would not find the modules in the external project (a Swift framework).
I have now figured out the reason for this. The project which contained the external framework was not set up correctly. It was set up to install the framework into a bogus location (/tmp/ProjectName.dst/Library/Frameworks, which is the default). In addition, my main project needed to add /Library/Frameworks into the framework search paths. It seems that when the project is built inside XCode, or for archiving etc... libraries and executables are built into a "private" folder structure separate from the system itself. When running xcodebuild install, however, it tries to install the external frameworks into the proper system folders, and link it there. Therefore, setups that work inside XCode may not work when running 'xcodebuild'.
EDIT: It works now, but StackOverflow won't let me mark it as correct before two days.
For one of my projects i used building script using packagemaker. Packagemaker allows specify all files i need install from root, so my root had following structure:
Applications
My Application.app
Library
Preferences
MyCompanyName
some.xml
another.xml
tmp
default.p12
usr
local
bin
sometool
I.e. it had following features:
Some configuration files preinstalled for all users, to global Preferences (some.xml, another.xml)
Some command line tool being used as by main app as user in /usr/local/bin
Program uses certificates and there is one default certificate which will be moved to right place in postflight
How to do same with productbuild? Possible?
The basic tool that does the packaging you want is pkgbuild, not productbuild. pkgbuild will let you specify a root directory that, upon installation, will be expanded to '/'. So, you can use that for all of what you discuss in your question (though an installer putting something in /tmp is a bit weird - I'd suggest baking the cert right into your postinstall script).