Is there any way to override build settings per person in Xcode? - xcode

I'm working on an iPhone app which connects to several services via REST API.
There are some servers for each service(development, production, etc),
and I want to switch these servers to connect by compiler flags WITHOUT modifying foo.xcodeproj/project.pbxproj.
I'm in a team of 6 developers and each person wants to connect to different servers combination,
but it will be a mess if I include these configuration in project.pbxproj which is managed by git.
So I need to change compiler flags with a file which is not managed by git.
Ideally, I want local settings mechanism like in Django.
Is there any ways to do this with Xcode?
Thanks! Any advice is highly appreciated.

Having your compiler flags not under source control is a huge RED FLAG. How can you guarantee consistent building of your app. // End Soap Box
Answer
I would create a user defined build setting for the production and dev servers. And a run script to set the server to use in the application info.plist
Add build setting REST_Server
Add run script to update the info.plist
# ---------------------------- IMPORTANT ----------------------------
# You must set RESTServer to something like 'Set by build script' in the file
# file '<Project Name>-Info.plist' in the 'Supporting Files' group
# -------------------------------------------------------------------
#
# determin server based on user name
#
SERVER=${REST_Server}
# Only use developer servers for debug never for release
if [ "$CONFIGURATION" != "Debug" ] ; then
exit
fi
if [ "$USER" == "gdunham" ] ; then
SERVER="gld.nextbigthing.com"
fi
if [ "$USER" == "jashmun" ] ; then
SERVER="jda.nextbigthing.com"
fi
echo $SERVER
#
# Set the server info in plist file in the build product not the source tree
#
/usr/libexec/PlistBuddy -c "Set :RESTServer $SERVER" "${TARGET_BUILD_DIR}/${INFOPLIST_PATH}"
Add place holder to info.plist
For all the gory details see my demo project on GitHub
https://github.com/GayleDDS/DemoMultiDeveloper

You can use the build configuration (.xcconfig)files to create different combinations of servers. Here is good explanation for how to configure this for your project: How can I use .xcconfig files in Xcode 4?
Each user can have their own .xcconfig file(s) and you can add these .xcconfig files to .gitignore

Related

Xcode Cloud: unable to open configuration settings file

I'm working with a React Native project, setting up Xcode Cloud builds.
I keep getting this error:
unable to open configuration settings file
Pods-XXX.debug.xcconfig:1
The files in my workspace look like the following:
|-- XXX
|-- Pods
|. -- Podfile
|. -- Targets Support Files
|. -- Pods-XXX
|. -- Pods-XXX.debug
Guess what? XCode is garbage but doc can help us here.
This what I'm using to smoothly build my workflow. I'l share exact bash scripts here.
Why it's failing?
First open logs on your workflow window side bar.
Check if you're installing necessary dependencies before running archive process. You're using virtual machine so any dependencies like cocoapods or yarn aren't installed by default there.
If you haven't read and skipped to the SOLUTION:
Here is the steps:
Create ci_scripts folder inside ios folder.
Create 3 files inside ci_scripts folder:
ci_post_clone.sh
ci_post_xcodebuild.sh
ci_pre_xcodebuild.sh
Inside your ci_post_clone.sh file add this:
#!/bin/zsh
# fail if any command fails
echo "🧩 Stage: Post-clone is activated .... "
set -e
# debug log
set -x
# Install dependencies using Homebrew. This is MUST! Do not delete.
brew install node yarn cocoapods fastlane
# Install yarn and pods dependencies.
# If you're using Flutter or Swift
# just install pods by "pod install" command
ls && cd .. && yarn && pod install
echo "🎯 Stage: Post-clone is done .... "
exit 0
Inside your ci_pre_xcodebuild.sh file add this:
#!/bin/zsh
echo "🧩 Stage: PRE-Xcode Build is activated .... "
# You can add additional scripts here...
echo "🎯 Stage: PRE-Xcode Build is DONE .... "
exit 0
Inside your ci_post_xcodebuild.sh file add this:
#!/bin/zsh
echo "🧩 Stage: POST-Xcode Build is activated .... "
# You can add additional scripts here...
echo "🎯 Stage: POST-Xcode Build is DONE .... "
exit 0
I've had this same issue recently, there is now a default workflow for xcode cloud that performs the post clone step that was provided by #BEK ROZ
I also had the same issue locally when building a VueJS app with Ionic/Capacitor
Before now my knowledge of iOS builds is precisely zero, so excuse innocence, but I found the issues were relating to the *xcconfig files. Every capacitor module that you install with npm will have it's own xcconfig file for debug and release - Stored in:
ios/App/Pods/Target Support Files/{{ Module Name }}/{{ Module Name }}.debug.xcconfig
ios/App/Pods/Target Support Files/{{ Module Name }}/{{ Module Name }}.release.xcconfig
I've only installed two plugins, so I uninstalled one of them, which was cordova-plugin-screen-orientation, synced and then archived (steps below) and this time it passed.
# Remove a capacitor module with npm e.g. cordova-plugin-screen-orientation
npm uninstall cordova-plugin-screen-orientation
# Sync the iOS plugins to remove the plugin from your Podfile (ios/App/Podfile)
npx cap sync ios
So I'd recommend going through all of the plugins you've installed and see if any of them are playing up. Then go back to xcode, run "Product -> Archive" from the menus to start a new build or push your changes and let xcode cloud do the heavy lifting for you.
Good luck

Install systemd service using autotools

I have an autotools project which successfully builds and tests an app (https://github.com/goglecm/AutoBrightnessCam). The app is installed in the bin directory (preceded by any prefix the user specifies). That's pretty straightforward. I now need to make a systemd service to start it at boot time. I've created the service file and ran it manually and it works fine.
The last bit is to tell configure.ac and Makefile.am to patch a *.service.in file with the correct path for the app (just like config.h is created from config.h.in).
Will using AC_CONFIG_HEADERS be appropriate to patch *.service.in into *.service? Is there another macro used for "non-headers" perhaps?
Also, how do I specify that the service file should land (i.e. installed) in /etc/systemd/system?
Is there perhaps a better way of starting this app at boot time without systemd?
How do I specify that the service file should land (i.e. installed) in /etc/systemd/system?
According to Systemd's daemon man page:
<BEGINQUOTE>
Installing systemd Service Files
At the build installation time (e.g. make install during package build), packages are recommended to install their systemd unit files in the directory returned by pkg-config systemd --variable=systemdsystemunitdir (for system services) or pkg-config systemd --variable=systemduserunitdir (for user services). This will make the services available in the system on explicit request but not activate them automatically during boot. Optionally, during package installation (e.g. rpm -i by the administrator), symlinks should be created in the systemd configuration directories via the enable command of the systemctl(1) tool to activate them automatically on boot.
Packages using autoconf(1) are recommended to use a configure script excerpt like the following to determine the unit installation path during source configuration:
PKG_PROG_PKG_CONFIG
AC_ARG_WITH([systemdsystemunitdir],
[AS_HELP_STRING([--with-systemdsystemunitdir=DIR], [Directory for systemd service files])],,
[with_systemdsystemunitdir=auto])
AS_IF([test "x$with_systemdsystemunitdir" = "xyes" -o "x$with_systemdsystemunitdir" = "xauto"], [
def_systemdsystemunitdir=$($PKG_CONFIG --variable=systemdsystemunitdir systemd)
AS_IF([test "x$def_systemdsystemunitdir" = "x"],
[AS_IF([test "x$with_systemdsystemunitdir" = "xyes"],
[AC_MSG_ERROR([systemd support requested but pkg-config unable to query systemd package])])
with_systemdsystemunitdir=no],
[with_systemdsystemunitdir="$def_systemdsystemunitdir"])])
AS_IF([test "x$with_systemdsystemunitdir" != "xno"],
[AC_SUBST([systemdsystemunitdir], [$with_systemdsystemunitdir])])
AM_CONDITIONAL([HAVE_SYSTEMD], [test "x$with_systemdsystemunitdir" != "xno"])
This snippet allows automatic installation of the unit files on systemd machines, and optionally allows their installation even on machines lacking systemd. (Modification of this snippet for the user unit directory is left as an exercise for the reader.)
Additionally, to ensure that make distcheck continues to work, it is recommended to add the following to the top-level Makefile.am file in automake(1)-based projects:
AM_DISTCHECK_CONFIGURE_FLAGS = \
--with-systemdsystemunitdir=$$dc_install_base/$(systemdsystemunitdir)
Finally, unit files should be installed in the system with an automake excerpt like the following:
if HAVE_SYSTEMD
systemdsystemunit_DATA = \
foobar.socket \
foobar.service
endif
...
</ENDQUOTE>
So it appears you should use systemdsystemunitdir and systemduserunitdir. How well Autotools supports it, well...
A quick grep on Fedora 31 using grep systemdsystemunitdir /bin/autoconf and grep -IR systemdsystemunitdir /usr/share shows no Autotools support yet. 7 years and counting...
Is there perhaps a better way of starting this app at boot time without systemd?
Systemd should be OK to start your app. Simply use systemctl(1) to enable and start them as you normally would.
Based on your GitHub and autobrightnesscam.service.in, I would not dick around with Autotools for this. You can waste copious amounts of time working around Autotols short comings (speaking from experience).
My configure.ac script (which is just a shell script) would copy autobrightnesscam.service.in to autobrightnesscam.service, and then use sed to copy-in the correct directories and files. Then, I would copy the updated autobrightnesscam.service to its proper location in AC_CONFIG_COMMANDS_POST. Maybe something like:
SERVICE_FILE=autobrightnesscam.service
SYSTEMD_DIR=`pkg-config systemd --variable=systemdsystemunitdir`
# Use default if SYSTEMD_DIR is empty
if test x"$SYSTEMD_DIR" = "x"; then
SYSTEMD_DIR=/etc/systemd/system
fi
AC_CONFIG_COMMANDS_POST([cp "$SERVICE_FILE" "$SYSTEMD_DIR"])
AC_CONFIG_COMMANDS_POST([systemctl enable "$SYSTEMD_DIR/$SERVICE_FILE"])
AC_CONFIG_COMMANDS_POST([systemctl start "$SERVICE_FILE"])
Will using AC_CONFIG_HEADERS be appropriate to patch *.service.in into *.service? Is there another macro used for "non-headers" perhaps?
No. AC_CONFIG_HEADERS is for setting up configuration headers to support your build. It is rarely used for anything other than building a config.h recording the results of certain tests that Autoconf performs, and it is not as flexible as other options in this area.
If you have additional files that you want Autoconf to build from templates then you should tell Autoconf about them via AC_CONFIG_FILES. Example:
AC_CONFIG_FILES([Makefile AutoBrightnessCam.service])
But if some of the data with which you are filling that template are installation directories then Autoconf is probably not the right place to do this at all, because it makes provision for the installation prefix to be changed by arguments to make. You would at least need to work around that, but the best thing to do is to roll with it instead, and build the .service file under make's control. It's not that hard, and there are several technical advantages, some applying even if there aren't any installation directory substitutions to worry about.
You can do it the same way that configure does, by running the very same template you're already using through sed, with an appropriate script. Something like this would appear in your Makefile.am:
SERVICE_SUBS = \
s,[#]VARIABLE_NAME[#],$(VARIABLE_NAME),g; \
s,[#]OTHER_VARIABLE[#],$(OTHER_VARIABLE),g
AutoBrightnessCam.service: AutoBrightnessCam.service.in
$(SED) -e '$(SERVICE_SUBS)' < $< > $#
Also, how do I specify that the service file should land (i.e.
installed) in /etc/systemd/system?
You use Automake's standard mechanism for specifying custom installation locations. Maybe something like this:
sytemdsysdir = $(sysconfdir)/systemd/system
systemdsys_DATA = AutoBrightnessCam.service
Is there perhaps a better way of
starting this app at boot time without systemd?
On a systemd-based machine, systemd is in control of what starts at boot. If you want the machine to start your application automatically at boot, then I think your options are limited to
Configuring systemd to start it
Configuring something in a chain of programs ultimately started by systemd to start it
Hacking the bootloader or kernel to start it
There is room for diverging opinions here, but I think the first of those is cleanest and most future-proof, and I cannot recommend the last.

Deployment with Deployment manager

I am trying to auto-deploy an application to a newly installed Websphere ND with Deployment Manager.
This is what I just did:
Install WebSphere
manageProfiles create, profile name="deployer", template = management, profile type = DEPLOYMENT_MANAGER, cell="ndcell", node="ndnode"
manageProfiles create, profile name="app", template = default, cell = knowncell, node = knownnode
AppServer/profiles/deployer/bin/startManager.sh
AppServer/profiles/app/bin/addNode.sh hostname (this all happens on one same host "hostname")
AppServer/bin/wsadmin -c '$AdminConfig modify [$AdminConfig showAttribute [$AdminConfig getid /Cell:ndcell] monitoredDirectoryDeployment] {{enabled true}}' - turn on monitored directory deployment
AppServer/bin/wsadmin -c '$AdminConfig save'
AppServer/profiles/deployer/bin/stopManager.sh, then startManager.sh
All right, at this point admin console shows one server "server1" which is not started, and there exists the directory AppServer/profiles/deployer/monitoredDeployableApps, that's the good part. The bad part is the directory is empty! There is no "server1" dir there, as it should be, to put my EAR into.
What am I missing?
You have to do a full synchronize in order to Dmgr deem changes to take effect

How to clone a WebSphere 8 profile

I would like to clone an existing profile, start the server and modify it via the Admin Console.
I already read the IBM documentation about
manageprofiles.bat
but the manageprofiles tool does not contain something like:
# would be nice if a clone action exists
manageprofiles.bat -clone -profileName base -targetProfileName base1
This is what I need and I don't see a way to achieve this.
The tool can create, delete, backup and restore a profile.
What I already tried
Copied the profile directory and renamed it
Edited the paths in the bin/setupCmdLine.bat
Added the profile to the AppServer/properties/profileRegistry.xml
Executed manageprofiles -validateAndUpdateRegistry
But the profile is still not recognized by WAS. I can verify this by executing
manageprofiles -listProfiles
How do you clone or copy profiles?
Is there a manual way?
If so, which files in the profile's dir must be edited?
Solved
Here are the manual steps that I did to clone an existent profile.
Make shure that the server is shutdown.
Copy the existent profile from Profiles/<oldProfile> to Profiles/<newProfile>
Update Path WAS_USER_SCRIPT in Profiles\<newProfile>\bin\setupCmdLine.bat
Update Path USER_INSTALL_ROOT in Profiles\<newProfile>\bin\setupCmdLine.bat
Update property user.root in Profiles\<newProfile>\properties\ssl.client.props
Replace all occurences of <oldProfile> with <newProfile> in Profiles\<newProfile>\firststeps\firststeps.bat
Edit AppServer\properties\profileRegistry.xml. Make a copy of the <oldProfile> and update the tag values with the <newProfile>. Should look something like this: <profile isAReservationTicket="false" isDefault="false" name="newProfile" path=".....\Profiles\newProfile" template=".......\AppServer\profileTemplates\default"/>
Copy AppServer\properties\fsdb\<oldProfile>.bat to AppServer\properties\fsdb\<newProfile>.bat. This step will make the profile available to "AppServer\bin\manageprofiles.bat -listProfiles"
Edit config/cells/<cell>/nodes/<node>/variables.xml. Update the USER_INSTALL_ROOT path.
Update the path of WAS_USER_SCRIPT in AppServer\properties\fsdb\<newProfile>.bat
This worked for me. Please comment or vote to let me know if it also worked for you.
Here is a build-in WebSphere solution. This works fine on WAS 8.5.5.3.
Run your application server in source profile
Run command line utility by running script <WAS_INSTAL_ROOT>/AppServer/profiles/<YOUR_SOURCE_PROFILE>/bin/wsadmin.sh or <WAS_INSTAL_ROOT>/AppServer/profiles/<YOUR_SOURCE_PROFILE>/bin/wsadmin.bat (on Windows machines)
Execute command in this utility:
$AdminTask exportWasprofile {-archive <PATH/TO/PROFILE/EXPORT/ARCHIVE>}
Create new target profile or use existing and run application server on it
Run command line utility for target profile by running script <WAS_INSTAL_ROOT>/AppServer/profiles/<YOUR_TARGET_PROFILE>/bin/wsadmin.sh or <WAS_INSTAL_ROOT>/AppServer/profiles/<YOUR_TARGET_PROFILE>/bin/wsadmin.bat (on Windows machines)
Execute command to import profile settings into target profile in this utility:
$AdminTask importWasprofile {-archive <PATH/TO/PROFILE/EXPORT/ARCHIVE> -deleteExistingServers}
Execute command to save new settings into target profile in this utility:
$AdminConfig save
I needed to do this today on WebSphere 8.5 Network Deployment, so I tracked it down and wrote a script. Here's how I do it.
Create a WebSphere profile using the GUI based Profile Management Tool.
Each one you create will write a log file to:
C:\Program Files (x86)\IBM\WebSphere\AppServer\logs\manageprofiles\XXXX_create.log
In the log, look for the -create switch. Clean up and copy that line into a script, modifying or parameterizing the fields as you wish:
SET PROFILENAME=Profile2
SET HOSTNAME=MyHostName
SET WAS_BIN=C:\Program Files (x86)\IBM\WebSphere\AppServer\bin
SET PROFILE_PATH=C:\Program Files (x86)\IBM\WebSphere\AppServer\profiles\%PROFILENAME%
SET WAS_TEMPLATE=C:\Program Files (x86)\IBM\WebSphere\AppServer\profileTemplates\default
SET WAS_CELL=%HOSTNAME%%PROFILENAME%Cell
SET WAS_PORTS_FILE=C:\Program Files (x86)\IBM\WebSphere\AppServer\logs\manageprofiles\was_default_portdef.props
SET A1=-create -serverName %PROFILENAME% -profileName %PROFILENAME% -cellName %WAS_CELL% -nodeName %PROFILENAME% -hostName %HOSTNAME%
SET A2=-profilePath "%PROFILE_PATH%" -templatePath "%WAS_TEMPLATE%"
SET A3=-applyPerfTuningSetting development -enableAdminSecurity false -winserviceCheck false -omitAction defaultAppDeployAndConfig
SET A4=-portsFile "%WAS_PORTS_FILE%"
SET A5=-signingCertDN "cn=10.0.2.15\\,ou=Root Certificate\\,ou=%WAS_CELL%\\,ou=%PROFILENAME%\\,o=IBM\\,c=US" -personalCertDN "cn=10.0.2.15\\,ou=%WAS_CELL%\\,ou=%PROFILENAME%\\,o=IBM\\,c=US"
SET A6=-personalCertValidityPeriod 10 -signingCertValidityPeriod 15
SET WAS_ARGS=%A1% %A2% %A3% %A4% %A5% %A6%
call "%WAS_BIN%\manageprofiles.bat" %WAS_ARGS%
You will need to look for the "C:\Program Files (x86)\IBM\WebSphere\AppServer\logs\manageprofiles*_portdef.props" files and copy one of them for your use as I did.
The output of my script was thus a cloned/tweaked version of a profile I had created before.
I then ran it at the commandline:
"C:\Program Files (x86)\IBM\WebSphere\AppServer\bin\manageprofiles.bat" -create -serverName Unica9103 -profileName Unica9103 -cellName UnicaVMUnica9103Cell -nodeName Unica9103 -hostName UnicaVM -profilePat
h "C:\Program Files (x86)\IBM\WebSphere\AppServer\profiles\Unica9103" -templatePath "C:\Program Files (x86)\IBM\WebSphere\AppServer\profileTemplates\default" -a
pplyPerfTuningSetting development -enableAdminSecurity false -winserviceCheck false -omitAction defaultAppDeployAndConfig -portsFile "C:\Program Files (x86)\IB
M\WebSphere\AppServer\logs\manageprofiles\was_default_portdef.props" -signingCertDN "cn=10.0.2.15\\,ou=Root Certificate\\,ou=UnicaVMUnica9103Cell\\,ou=Unica9103
\\,o=IBM\\,c=US" -personalCertDN "cn=10.0.2.15\\,ou=UnicaVMUnica9103Cell\\,ou=Unica9103\\,o=IBM\\,c=US" -personalCertValidityPeriod 10 -signingCertValidityPeri
od 15
Notice that the commas need to be escaped with double backslashes or you get cryptic errors.
You will get something like the following on success:
INSTCONFSUCCESS: Success: Profile Unica9103 now exists. Please consult C:\Program Files (x86)\IBM\WebSphere\AppServer\profiles\Unica9103\logs\AboutThisProfile.txt for more information about this profile.
I have not tested the method but wsadmin has the following command:
createAppServerTemplate
This script creates a new application server template in your
configuration. A server template is used to define the configuration
settings for a new application server. When you create a new
application server, you either select the default server template or a
template you previously created, that is based on another, already
existing application server. The default template is used if you do
not specify a different template when you create the server.
You could create a template from your initial profile and create a new profile using the template.
I believe that createAppServerTemplate creates e template for the server not the profile. Therefore if you already have configured a profile you can than use the template to create additional servers within this profile.
You would then use createApplicationServer to create new servers based on the above created template.
I guess if you want to copy a profile the best method is to record the configurations and set them in a script file.
Just for information In MyEclipseBlue version 10 we can export server profile configuration & import in new profile; hence retaining all the configuration.
René answer is correct but i faced issues while Running the server in Debug Mode.
\WebSphere8552\AppServer\properties\fsdb\AppSrv01.bat change was_user_script path
\WebSphere8552\AppServer\properties\fsdb_was_profile_defauldefault.bat change was_user_script path with actual
Also change path in : \AppServer\properties\profileRegistry.xml for validating license

Mogenerator and Xcode 4

I just installed mogenerator+xmo'd on my development machine and would like to start playing with it. The only instructions I could really find online were from a previous SO post, and those don't work with XCode 4 (or at least ⌘I doesn't pull up metadata any more and I don't know how).
So to get things up and running, is all that needs to happen to add xmod in the .xcdatamodeld's comments (wherever they are) and the classes will be generated/updated on save from then on?
While trying to find this answer myself, I found MOGenerator and Xcode 4 integration guide on esenciadev.com. This solution is not a push-button integration, but it works. The link has detailed instructions, but generally you:
Copy the shell scripts into your project
Add build rules to your target to run the two shell scripts
When you build your project, the script runs MOGenerator on all .xcdatamodel files in your project directory. After the build, if the script generates new class files, you must manually add them to your project. Subsequent builds will remember existing MO-Generated files.
Caveats:
The example's build rule assumes you put the scripts into a /scripts/ file folder within your project directory. When I ignored this detail (creating a project folder but not a file folder) I got a build error. Make sure the build rule points to the script's file location.
The script uses the --base-class argument. Unless your model classes are subclasses of a custom class (not NSManagedObject), you must delete this argument from the script. E.g.,
mogenerator --model "${INPUT_FILE_PATH}/$curVer" --output-dir "${INPUT_FILE_DIR}/" --base-class $baseClass
Now that Xcode 4 is released Take a look at the Issues page for mogenerator
After I make changes to my model file, I just run mogenerator manually from the terminal. Using Xcode 4 and ARC, this does the trick:
cd <directory of model file>
mogenerator --model <your model>.xcdatamodeld/<current version>.xcdatamodel --template-var arc=YES
Maybe I'll use build scripts at some point, but the terminal approach is too simple to screw up.
I've found a Script in the "Build Phases" to be more reliable than the "Build Rules".
Under "Build Phases" for your Target, choose the button at the bottom to "Add Run Script". Drag the run script to the top so that it executes before compiling sources.
Remember that the actual data model files (.xcdatamodel) are contained within a package (.xcdatamodeld), and that you only need to compile the latest data model for your project.
Add the following to the script (replacing text in angle-brackets as appropriate)
MODELS_DIR="${PROJECT_DIR}/<path to your models without trailing slash>"
DATA_MODEL_PACKAGE="$MODELS_DIR/<your model name>.xcdatamodeld"
CURRENT_VERSION=`/usr/libexec/PlistBuddy "$DATA_MODEL_PACKAGE/.xccurrentversion" -c 'print _XCCurrentVersionName'`
# Mogenerator Location
if [ -x /usr/local/bin/mogenerator ]; then
echo "mogenerator exists in /usr/local/bin path";
MOGENERATOR_DIR="/usr/local/bin";
elif [ -x /usr/bin/mogenerator ]; then
echo "mogenerator exists in /usr/bin path";
MOGENERATOR_DIR="/usr/bin";
else
echo "mogenerator not found"; exit 1;
fi
$MOGENERATOR_DIR/mogenerator --model "$DATA_MODEL_PACKAGE/$CURRENT_VERSION" --output-dir "$MODELS_DIR/"
Add options to mogenerator as appropriate. --base-class <your base class> and --template-var arc=true are common.
Random tip. If you get Illegal Instruction: 4 when you run mogenerator. Install it from the command line:
$ brew update && brew upgrade mogenerator

Resources