If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Rename project build configurations to match modern project files

RESOLVED FIXED in Camino2.1

Status

Camino Graveyard
General
RESOLVED FIXED
8 years ago
7 years ago

People

(Reporter: Smokey Ardisson (offline for a while; not following bugs - do not email), Assigned: Stuart Morgan)

Tracking

Trunk
Camino2.1
All
Mac OS X

Details

Attachments

(1 attachment, 1 obsolete attachment)

v2
63.75 KB, patch
Smokey Ardisson (offline for a while; not following bugs - do not email)
: feedback+
Details | Diff | Splinter Review
Right now our project has the old "Development" and "Deployment" build configuration names, while modern projects use "Debug" and "Release".  Besides being old and phonetically confusing, this creates implementation "hassles" when integrating third-party projects (for bug 518615, I'm going to have to change our project, xcconfig, and Makefile because the build configuration names no longer match up with the new Growl project).

Stuart mentioned before that this might have other implications throughout the build system, so we'd want to do this carefully and watch (and not, say, before 2.0).
(Assignee)

Comment 1

7 years ago
Created attachment 448374 [details] [diff] [review]
fix

This worked in my Debug and Release (yay!) builds, so it looks like there weren't too many ripple effects. And we have one less local mod to a third-party project :)

Smokey, can you kick the tires on this just to get a second opinion on it building?

(I know that changing the symbol generation for third-party frameworks to point to $CONFIGURATION is a bit weird, since they don't use DWARF in Debug, but leaving it pointing to Release is even more silly since it's not built at all. At least this way someone could locally change the projects to generate DWARF symbols to test in Debug.)
Assignee: nobody → stuart.morgan+bugzilla
Status: NEW → ASSIGNED
Attachment #448374 - Flags: superreview?(mikepinkerton)
Attachment #448374 - Flags: feedback?(alqahira)
Comment on attachment 448374 [details] [diff] [review]
fix

rs=pink
Attachment #448374 - Flags: superreview?(mikepinkerton) → superreview+
Comment on attachment 448374 [details] [diff] [review]
fix

Per irc, this doesn't work on 10.5; Xcode/xcodebuild tries to copy the frameworks out of $(OBJDIR)/camino/build/$(BUILDSTYLE)/ rather than $(OBJDIR)/camino/$(3RDPARTYITEM)/build/$(BUILDSTYLE)/
Attachment #448374 - Flags: feedback?(alqahira) → feedback-
(Assignee)

Comment 4

7 years ago
Created attachment 448420 [details] [diff] [review]
v2

That's a well-established Xcode bug that I'd forgotten about despite having to deal with it in the past. On the bright side the fact that it works for me suggests the finally fixed in in the 10.6 toolchain.

This includes the standard workaround to this problem: manually copy the frameworks into the Camino build target directory, so when Xcode looks there for whatever inexplicable reason, it finds them. I've tried to make sure it will happen in the right order, but I can't test on 10.6 since it already works.
Attachment #448374 - Attachment is obsolete: true
Attachment #448420 - Flags: feedback?(alqahira)
Attachment #448420 - Flags: feedback?(alqahira) → feedback+
Comment on attachment 448420 [details] [diff] [review]
v2

>+		005C9E1111B44D3D002FAA43 /* Copy Frameworks to Build Dir */ = {
>+			isa = PBXShellScriptBuildPhase;
>+			buildActionMask = 2147483647;
>+			files = (
>+			);
>+			inputPaths = (
>+			);
>+			name = "Copy Frameworks to Build Dir";
>+			outputPaths = (
>+				"${BUILT_PRODUCTS_DIR}/Breakpad.framework",
>+				"${BUILT_PRODUCTS_DIR}/Growl.framework",
>+				"${BUILT_PRODUCTS_DIR}/Sparkle.framework",
>+			);
>+			runOnlyForDeploymentPostprocessing = 0;
>+			shellPath = /bin/sh;
>+			shellScript = "\"${SRCROOT}/scripts/copy-third-party-frameworks.sh\"";
>+			showEnvVarsInLog = 0;
>+		};
>+		005C9E1711B44D66002FAA43 /* Copy Frameworks to Build Dir */ = {
>+			isa = PBXShellScriptBuildPhase;
>+			buildActionMask = 2147483647;
>+			files = (
>+			);
>+			inputPaths = (
>+			);
>+			name = "Copy Frameworks to Build Dir";
>+			outputPaths = (
>+				"${BUILT_PRODUCTS_DIR}/Breakpad.framework",
>+				"${BUILT_PRODUCTS_DIR}/Growl.framework",
>+				"${BUILT_PRODUCTS_DIR}/Sparkle.framework",
>+			);
>+			runOnlyForDeploymentPostprocessing = 0;
>+			shellPath = /bin/sh;
>+			shellScript = "\"${SRCROOT}/scripts/copy-third-party-frameworks.sh\"";
>+			showEnvVarsInLog = 0;
>+		};

These are now the first shell script build phases, so they should show env vars instead of the "Copy Crash Reporter InfoPlist.strings Override" phases.

>diff --git a/scripts/copy-third-party-frameworks.sh b/scripts/copy-third-party-frameworks.sh
>new file mode 100755
>--- /dev/null
>+++ b/scripts/copy-third-party-frameworks.sh
>@@ -0,0 +1,19 @@
>+#!/bin/bash
>+# Xcode doesn't understand that our third-party frameworks are built into different directories
>+# than Camino is built into, so doing a normal copy phase doesn't work. Instead, we copy them
>+# manually.
>+# (This issue seems to be fixe in Snow Leopard, so we can hopefully eliminate this someday)
>+

Have this script echo what it's doing/purpose is at the start, just like the regular shell-script build phases.

r/f=ardissone with those changes.
(Assignee)

Comment 6

7 years ago
Landed 3104:424de5db1c9b with those changes.
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.