296900 - Xcode 2.1: need to support per-build configuration build directories

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Mark Mentovai]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050605 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050605 Firefox/1.0+

Xcode 2.1 was released earlier today.  It breaks our build process, because
build products are now placed in a build configuration-specific directory. 
(Build configurations replace build styles.)  In the past, we used to be able to
rely on finding build products of xcodebuild (or pbbuild or pbxbuild) in a
project's build subdirectory.  Now, we need to look in build/Development or
build/Deployment.

Because of this, a build under Xcode 2.1 will fail after xcodebuild, because the
Mozilla build system does not find the products where it expects them.  This
affects DefaultPlugin, PrintPDE, and Camino.

For example:
|NEXT_ROOT= /usr/bin/xcodebuild -project DefaultPlugin.xcode -target "Default
Plugin" -buildstyle Development GCC_VERSION="4.0"
|deprecated option: -buildstyle is no longer supported in xcodebuild. Use
-configuration instead.
|(NOTE: project DefaultPlugin was written by an older version of Xcode (39) --
temporarily upgrading it to version 42 (without modifying project file))
|
|=== BUILDING NATIVE TARGET Default Plugin WITH CONFIGURATION Development ===
|** BUILD SUCCEEDED **
|echo -n NSPLMOSS > "build/DefaultPlugin.build/Default Plugin.build/PkgInfo"
|/bin/sh: line 1: build/DefaultPlugin.build/Default Plugin.build/PkgInfo: No
such file or directory

We need to detect Xcode > 2.1 and treat this case accordingly.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Mark Mentovai]

Attachment: v1

xcodebuild can be told to use the "old" location for build products on the
command line.  DefaultPlugin is also modified so that its PkgInfo is placed
directly in the plugin after it is built, rather than being placed elsewhere
and copied separately.

The drawback here is that Xcode's defaults are overridden on the command line,
so builds done from within Xcode.app aren't adjusted.  This may be a minor
nuisance, especially for Camino, but it's not as bad as it seems.  I'm leaving
the actual build directory set to its default, it's only the build product
directory, to which products are copied after building, that I'm overriding.

Speaking of Camino, I haven't yet tested this patch with it, although I've got
a build cooking right now.  I don't anticipate trouble.

The alternative is to have the Mozilla build system test for the Xcode version
and adjust itself to use the new paths as appropriate.	The problem is that
there's no really good "official" way to get the Xcode version.  "xcodebuild
-version" seems most appropriate, but as of 2.1, it produces the non-intuitive
output "DevToolsCore-620.0; DevToolsSupport-610.0".  For older versions of
xcodebuild (some of which may call themselves pbxbuild or pbbuild), -version
isn't even recognized.	At least for now, I think that overriding the new
default to match the old is preferrable to obscure version parsing.

Comment 2

[Mark Mentovai]

Attachment: v2: oops, screwed up a path

-+	echo -n NSPLMOSS > "build/Default Plugin.plugin/PkgInfo"
++	echo -n NSPLMOSS > "build/Default Plugin.plugin/Contents/PkgInfo"

Comment 3

[Mark Mentovai]

Attachment: v3, handle Camino too

The main Camino target during the Camino build refers to the products built in
the other targets in that project.  BUILT_PRODUCTS_DIR is needed to tell Xcode
where to find them.

Also, while I'm at it, I'm removing the extraneous "all" target from the
DefaultPlugin Makefile.  rules.mk brings in a correct "all" target, having an
extra one means that a "make" in that directory calls for xcodebuild twice.

Comment 4

[Benjamin Smedberg]

Comment on attachment 185533 [details] [diff] [review]
v3, handle Camino too

I'm not a superreviewer but this is a build-config change only, which according
to the rules does not require sr. Marking third-review for good measure, and
a=me

Comment 5

[Josh Aas]

Checking in config/config.mk;
/cvsroot/mozilla/config/config.mk,v  <--  config.mk
new revision: 3.320; previous revision: 3.319
done
Checking in modules/plugin/samples/default/mac/Makefile.in;
/cvsroot/mozilla/modules/plugin/samples/default/mac/Makefile.in,v  <--  Makefile.in
new revision: 1.12; previous revision: 1.11
done

Comment 6

[Mark Mentovai]

Reopening to handle this a better way

Comment 7

[Mark Mentovai]

Attachment: Make build system understand new Xcode layout

The initial patch forced Xcode 2.1 to use the build product directories that
Xcode 2.0 used.  That caused some unnecessary churning when building a project
from the Xcode UI or running "xcodebuild" manually at the CLI.	(In the latter
case, I suggest using "make" instead though.)

This update adds a configure check for the Xcode version, and if it indicates
2.1 or later, the make machinery will look for build products in the new-style
directories.  Testers, remember to autoconf.

Comment 8

[Mark Mentovai]

Attachment: Better "test"

Right - test doesn't short-circuit.

-+	  if test -n "$XCODEBUILD_VERSION" -a "$XCODEBUILD_VERSION" -ge 620 ;
then
++	  if test -n "$XCODEBUILD_VERSION" && test "$XCODEBUILD_VERSION" -ge
620 ; then

Comment 9

[Mark Mentovai]

Attachment: Camino portion

Adjust paths in Camino.xcode where needed.

Comment 10

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 186552 [details] [diff] [review]
Camino portion

does |$TARGET_BUILD_DIR| work as expected in using Xcode pre-2.1? Just
checking.

does the change for the default plugin work with objdir builds?

Comment 11

[Mark Mentovai]

(In reply to comment #10)
> does |$TARGET_BUILD_DIR| work as expected in using Xcode pre-2.1? Just
> checking.

Tested with Xcode 1.1 on 10.3.9, and yes, you wind up with a Rezzed Camino.rsrc
in the app bundle.

> does the change for the default plugin work with objdir builds?

It does.  I only work with objdir builds.

But at least as it stands now, Default Plugin isn't copied into the Camino app
bundle.  It's present in the project only as a file reference, there's no
corresponding copy phase for it.

On the other hand, it IS copied into Firefox, where it's superseded by the PFS,
but that's bug 261751.

Comment 12

[Mark Mentovai]

Attachment: Camino, two birds, one stone

The Default Plugin not being included is probably an accident.	Since I'm
messing with it in this patch anyway, it might as well go back in to the app
bundle.

Note that the patch in attachment 186531 [details] [diff] [review] (not this patch, the core one) will
bust any automated Camino packagers using Xcode 2.1, if the packager depends on
Camino.app being in camino/build/Camino.app.  The only thing that seems to be
affected (according to lxr) is /tools/tinderbox/build-camino.pl.  The best
solution is to adapt Camino's Makefile to copy the built Camino.app from
whereever the build system decided it was placed into objdir/dist/Camino.app,
and use that as the jumping-off point for any automated packaging.  I'm not
touching this yet - it's not crucial until any automated packager is on 2.1.

Comment 13

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 186697 [details] [diff] [review]
Camino, two birds, one stone

r=pink

Comment 14

[Josh Aas]

landed on trunk